Counting the number of passengers entering a ridesharing vehicle

ABSTRACT

A ridesharing vehicle, comprising a vehicle body; a communications interface within the vehicle body for wirelessly communicating with a remote server configured to electronically receive shared-ride requests from a plurality of users; at least one sensor associated with the vehicle body and configured to detect entry of passengers from the ridesharing vehicle; at least one processor within the vehicle body, the at least one processor being programmed to receive, via the communications interface, information about passengers to be picked up, the received information including a pick-up location and a scheduled number of passengers expected to be picked up at the pick-up location; after arriving at the pick-up location, receive from the at least one sensor a number of passengers actually picked up at the pick-up location; compare the actual number of passengers picked up at the pick-up location with the scheduled number of passengers; and initiate a remedial action when a difference exists between the scheduled number of passengers and the actual number of passengers as detected by the at least one sensor.

CROSS REFERENCES TO RELATED APPLICATIONS

This application claims the benefit of priority of U.S. ProvisionalPatent Application No. 62/537,155, filed Jul. 26, 2017, and U.S.Provisional Patent Application No. 62/614,558, filed Jan. 8, 2018. Allof the foregoing applications are incorporated herein by reference intheir entirety.

BACKGROUND I. Technical Field

The present disclosure generally relates to the field of vehicleridesharing and systems and methods for routing ridesharing vehicles andfor ridesharing management.

II. Background Information

Recent years have witnessed increasing interest and development in thefield of vehicle sharing, where one or more riders may share the samevehicle for a portion of their rides. Ridesharing may save ride costs,increase vehicle utilization, and reduce air pollution. A rider may usea ridesharing service through a ridesharing service application accessedby the rider's mobile device.

SUMMARY

Embodiments consistent with the present disclosure provide systems andmethods for vehicle ridesharing and for managing a fleet of ridesharingvehicles. For example, consistent with the disclosed embodiments, thefleet of ridesharing vehicles may include more than 10 ridesharingvehicles, more than 100 ridesharing vehicles, or more than 1000ridesharing vehicles that pick up multiple users and drop them off atlocations proximate but other than their desired destinations.

In one embodiment, a ridesharing vehicle may include a vehicle body, acommunications interface within the vehicle body for wirelesslycommunicating with a remote server configured to electronically receiveshared-ride requests from a plurality of users, at least one sensorassociated with the vehicle body and configured to detect entry ofpassengers from the ridesharing vehicle, and at least one processorwithin the vehicle body. The at least one processor within the vehiclebody may be programmed to receive, via the communications interface,information about passengers to be picked up, the received informationincluding a pick-up location and a scheduled number of passengersexpected to be picked up at the pick-up location, after arriving at thepick-up location, receive from the at least one sensor a number ofpassengers actually picked up at the pick-up location, compare theactual number of passengers picked up at the pick-up location with thescheduled number of passengers, and initiate a remedial action when adifference exists between the scheduled number of passengers and theactual number of passengers as detected by the at least one sensor.

In one embodiment, a method for method for counting a number ofpassengers entering a ridesharing vehicle may include receiving from aremote server information about passengers to be picked up, the receivedinformation including a pick-up location and a scheduled number ofpassengers expected to be picked up at the pick-up location, receiving,from at least one sensor configured to detect entry of passengers fromthe ridesharing vehicle, a number of passengers actually picked up atthe pick-up location, comparing the actual number of passengers pickedup at the pick-up location with the scheduled number of passengers, andinitiating a remedial action when a difference exists between thescheduled number of passengers and the actual number of passengers asdetected by the at least one sensor.

In one embodiment, a system for directing an electric vehicle to acharging station may include a memory for storing historical dataassociated with past demand for ridesharing vehicles in a geographicalarea and locations of a plurality of charging stations in thegeographical area, a communication interface for communicating with afleet of ridesharing vehicles including a plurality of electricvehicles, and at least one processor programmed to access the memory.The at least one processor may be programmed to receive, via thecommunications interface, current battery-charge data for the pluralityof electric vehicles, wherein the current battery-charge data isreflective of a distance that each electric vehicle can operate beforerecharging, identify, from the current battery-charge data, a specificelectric vehicle traveling in the geographic area and in need of acharge, receive current vehicle location data for the specific electricvehicle, wherein the current vehicle location data includes globalpositioning system (GPS) data generated by at least one GPS componentassociated with the specific electric vehicle, determine, using thehistorical data, predicted demand for ridesharing requests in at leastone area proximate to at least one of the plurality of chargingstations, based on an estimated charging completion time and thepredicted demand, select a charging station for the specific electricvehicle, wherein the selected charging station is other than a chargingstation closest to a current location of the specific electric vehicle,and direct the specific electric vehicle to the selected chargingstation.

In one embodiment, a system for directing an electric vehicle to acharging station may include memory for storing locations of a pluralityof charging stations in the geographical area, a communication interfacefor communicating with a fleet of ridesharing vehicles including aplurality of electric vehicles, and at least one processor. The at leastone processor may be programmed to access the memory and to: receive,via the communications interface, current battery-charge data for theplurality of electric vehicles, wherein the current battery-charge datais reflective of a distance that each electric vehicle can operatebefore recharging; identify, from the current battery-charge data, aspecific electric vehicle traveling in the geographic area and in needof a charge; receive current vehicle location data for the specificelectric vehicle, wherein the current vehicle location data includesglobal positioning system (GPS) data generated by at least one GPScomponent associated with the specific electric vehicle; receive, viathe communications interface, current occupancy data for the pluralityof charging stations, wherein the current occupancy data includes anestimated charging completion time for each charging station; based onthe estimated charging completion time, select a charging station forthe specific electric vehicle, wherein the selected charging station isother than a charging station closest to a current location of thespecific electric vehicle; and direct the specific electric vehicle tothe selected charging station.

In one embodiment, a method for directing an electric vehicle to acharging station may include accessing a memory configured to storehistorical data associated with past demand for ridesharing vehicles ina geographical area and locations of a plurality of charging stations inthe geographical area, communicating with a fleet of ridesharingvehicles including a plurality of electric vehicles, receiving currentbattery-charge data for the plurality of electric vehicles, wherein thecurrent battery-charge data is reflective of a distance that eachelectric vehicle can operate before recharging, identifying, from thecurrent battery-charge data, a specific electric vehicle traveling inthe geographic area and in need of a charge, receiving current vehiclelocation data for the specific electric vehicle, wherein the currentvehicle location data includes global positioning system (GPS) datagenerated by at least one GPS component associated with the specificelectric vehicle, determining, using the historical data, predicteddemand for ridesharing requests in at least one area proximate at leastone of the plurality of charging stations, based on an estimatedcharging completion time and the predicted demand, selecting a chargingstation for the specific electric vehicle, wherein the selected chargingstation is other than a charging station closest to a current locationof the specific electric vehicle, and directing the specific electricvehicle to the selected charging station.

In one embodiment, a system may direct electrically-powered vehicles andpetrol-powered vehicles to different locations. The system may include acommunications interface for communicating with a fleet of vehiclesincluding electrically-powered vehicles and petrol-powered vehicles andfor receiving requests for rides from a plurality of users, and at leastone processor. The at least one processor may be programmed to receive,via the communications interface, a first request for a ride from afirst user, the first request including information related to a firstpick-up location of the first user and a first desired destination ofthe first user; receive, via the communications interface, a secondrequest for a ride from a second user, the second request includinginformation related to a second pick-up location of the second user anda second desired destination of the second user; receive currentbattery-charge data for the electrically-powered vehicles, wherein thecurrent battery-charge data is indicative of a distance in which eachelectrically-powered vehicle can operate without charging; receivecurrent vehicle location data for the fleet of vehicles, wherein thecurrent vehicle location data includes global positioning system (GPS)data generated by at least one GPS component associated with eachvehicle; based on the first and second desired destinations, the currentbattery-charge data, and the current vehicle location data,electronically assign the first user to a first electrically-poweredvehicle and the second user to a second petrol-powered vehicle; andtransmit, via the communications interface, instructions to direct thefirst electrically-powered vehicle to the first pick-up location and thesecond petrol-powered vehicle to the second pick-up location.

In one embodiment, a method may direct electrically-powered vehicles andpetrol-powered vehicles to different locations. The method may includecommunicating with a fleet of vehicles including electrically-poweredvehicles and petrol-powered vehicles; receiving a first request for aride from a first user, the first request including information relatedto a first pick-up location of the first user and a first desireddestination of the first user; receiving a second request for a ridefrom a second user, the second request including information related toa second pick-up location of the second user and a second desireddestination of the second user; receiving current battery-charge datafor the electrically-powered vehicles, wherein the currentbattery-charge data is indicative of a distance in which eachelectrically-powered vehicle can operate without charging; receivingcurrent vehicle location data for the fleet of vehicles, wherein thecurrent vehicle location data includes global positioning system (GPS)data generated by at least one GPS component associated with eachvehicle; based on the first and second desired destinations, the currentbattery-charge data, and the current vehicle location data,electronically assigning the first user to a first electrically-poweredvehicle and the second user to a second petrol-powered vehicle; anddirecting the first electrically-powered vehicle to the first pick-uplocation and the second petrol-powered vehicle to the second pick-uplocation.

In one embodiment, a system may direct manually-drivable vehicles andautonomous vehicles. The system may include at least one communicationsinterface for receiving ride requests from a plurality of users and forcommunicating with a plurality of vehicles-for-hire includingmanually-drivable vehicles and autonomous vehicles; memory storinginformation identifying a driving mode of each vehicle-for-hire aseither a manually-drivable vehicle or an autonomous vehicle, andinformation identifying roads restricted to at least one ofmanually-drivable vehicles and autonomous vehicles; and at least oneprocessor. The at least one processor may be programmed to receive, viathe communications interface, a ride request from a prospectivepassenger, the ride request including information related to a pick-uplocation and a drop-off location of the prospective passenger; receivecurrent vehicle location data for the plurality of vehicles-for-hire,wherein the current vehicle location data includes global positioningsystem (GPS) data generated by at least one GPS component associatedwith each vehicle-for-hire; electronically assign a specificvehicle-for-hire with capacity to fulfill the ride request to pick upthe prospective passenger based on the current vehicle location data;access the stored information to determine the driving mode of thespecific vehicle-for-hire; select a mode-specific route for the specificvehicle-for-hire that avoids roads restricted to the specificvehicle-for-hire based on the driving mode of the specificvehicle-for-hire; and wirelessly transmit the selected mode-specificroute to the specific vehicle-for-hire.

In one embodiment, a method may direct manually-drivable vehicles andautonomous vehicles. The method may include communicating with aplurality of vehicles-for-hire including manually-drivable vehicles andautonomous vehicles; accessing stored information identifying a drivingmode of each vehicle-for-hire as either a manually-drivable vehicle oran autonomous vehicle, and information identifying roads restricted toat least one of manually-drivable vehicles and autonomous vehicles;receiving a ride request from a prospective passenger, the ride requestincluding information related to a pick-up location and a drop-offlocation of the prospective passenger; receiving current vehiclelocation data for the plurality of vehicles-for-hire, wherein thecurrent vehicle location data includes global positioning system (GPS)data generated by at least one GPS component associated with eachvehicle-for-hire; electronically assigning a specific vehicle-for-hirewith capacity to fulfill the ride request to pick up the prospectivepassenger based on the current vehicle location data; accessing thestored information to determine the driving mode of the specificvehicle-for-hire; selecting a mode-specific route for the specificvehicle-for-hire that avoids roads restricted to the specificvehicle-for-hire based on the driving mode of the specificvehicle-for-hire; and wirelessly transmitting the selected mode-specificroute to the specific vehicle-for-hire.

In one embodiment, an autonomous vehicle-for-hire may comprise a vehiclebody; at least one sensor associated with the vehicle body for sensingtraffic conditions in a vicinity of the vehicle-for-hire; acommunications interface for communicating with a remote serverconfigured to electronically receive ride requests from prospectivepassengers; and at least one processor. The at least one processor maybe programmed to receive from the remote server data identifying apick-up location of a specific passenger and data identifying a drop-offlocation for the specific passenger; electronically direct theautonomous vehicle-for-hire to pick up the specific passenger at thepick-up location; after picking up the specific passenger,electronically direct the autonomous vehicle-for-hire to drop off thespecific passenger at the drop-off location; receive from the at leastone sensor traffic data associated with the drop-off location, when theautonomous vehicle-for-hire is in a vicinity of the drop-off location;enable a comparison of the traffic data obtained from the at least onesensor with safety data to determine whether dropping off the specificpassenger at the drop-off location complies with a safety threshold;when it is determined that a drop off at the drop-off location fails tomeet the safety threshold, enable analysis of the traffic data obtainedfrom the at least one sensor to identify an alternative location, in avicinity of the drop-off location, that complies with the safetythreshold; and direct the vehicle-for-hire to the alternative location,to drop off the specific passenger at the alternative location.

In one embodiment, a method for dropping off passengers at a safelocation may comprise communicating with a remote server configured toelectronically receive ride requests from prospective passengers;receiving from the remote server data identifying a pick-up location ofa specific passenger and data identifying a drop-off location for thespecific passenger; electronically directing the autonomous vehicle topick up the specific passenger at the pick-up location; after pickingup, electronically directing the autonomous vehicle to drop off thespecific passenger at the drop-off location; receive from at least onesensor configured to sense traffic conditions in a vicinity of thevehicle-for-hire traffic data associated with the drop-off location;enabling a comparison of the traffic data obtained from the at least onesensor with safety data to determine whether dropping off the specificpassenger at the drop-off location complies with a safety threshold;when it is determined that a drop off at the drop-off location fails tomeet the safety threshold, enabling analysis of the traffic dataobtained from the at least one sensor to identify an alternativelocation, in a vicinity of the drop-off location, that complies with thesafety threshold; and directing the vehicle-for-hire to the alternativelocation, to drop off the specific passenger at the alternativelocation.

In one embodiment, a method for picking up passengers from a safelocation may comprise communicating with a remote server configured toelectronically receive ride requests from prospective passengers;receiving from the remote server data identifying a pick-up location ofa specific passenger and data identifying a drop-off location for thespecific passenger; electronically directing the autonomous vehicle topick up the specific passenger at the pick-up location; before pickingup the specific passenger at the pick-up location, receiving from atleast one sensor configured to sense traffic conditions in a vicinity ofthe vehicle-for-hire traffic data associated with the pick-up location;enabling a comparison of the traffic data obtained from the at least onesensor with safety data to determine whether picking up the specificpassenger at the pick-up location complies with a safety threshold;determining that a pick up at the pick-up location fails to meet thesafety threshold; analyzing the traffic data obtained from the at leastone sensor to identify an alternative pick-up location, in a vicinity ofthe pick-up location, that complies with the safety threshold; directingthe vehicle-for-hire to the alternative pick-up location, to pick up thespecific passenger at the alternative pick-up location; and causing amessage including a description of the alternative pick-up location tobe transmitted to the specific passenger.

In one embodiment, a system may direct a ridesharing vehicle. The systemmay include a communications interface and at least one processor. Thecommunications interface may be configured to receive requests forshared-rides from a plurality of users. The at least one processor maybe configured to receive during a first time period, via thecommunications interface, a first request for a shared-ride from a firstuser. The first request including information indicative of a firststarting point, a first desired destination, and a first requestedpick-up time, wherein the first requested pick-up time is during asecond time period more than two hours after the first time period. Theat least one processor may also be configured to receive during thefirst time period, via the communications interface, a second requestfor a shared ride from a second user. The second request may includeinformation indicative of a second starting point different from thefirst starting point, a second desired destination different from thefirst desired destination, and a second requested pick-up time duringthe second time period. The at least one processor may further beconfigured store the first and second requests for processing during athird time period, where the third time period for processing is morethan one hour after the first time period but before the second timeperiod. During the third time period, the at least one processor may beconfigured to receive current vehicle location data for a plurality ofridesharing vehicles, wherein the current vehicle location data includesglobal positioning system (GPS) data generated by at least one GPScomponent associated with each of the plurality of ridesharing vehicles;process the first request, the second request, and the vehicle locationdata to identify a specific ridesharing vehicle for transporting boththe first user and the second user; and calculate a ridesharing routefor picking up the first user and the second user, wherein calculatingthe ridesharing route includes determining pick-up locations for thefirst user and the second user that differ from the first starting pointand the second starting point. After the third time period and beforethe second time period, the at least one processor may be configured towirelessly transmit to the first user and the second user the respectivepick-up locations; and wireless transmit to the specific ridesharingvehicle, the calculated route for picking up the first and second userduring the second time period.

In another embodiment, a method may direct ridesharing vehicles. Themethod may include receiving during a first time period, via thecommunications interface, a first request for a shared-ride from a firstuser, the first request including information indicative of a firststarting point, a first desired destination, and a first requestedpick-up time, wherein the first requested pick-up time is during asecond time period more than two hours after the first time period;receiving during a first time period, via the communications interface,a second request for a shared ride from a second user, the secondrequest including information indicative of a second starting pointdifferent from the first starting point, a second desired destinationdifferent from the first desired destination, and a second requestedpick-up time during the second time period; storing the first and secondrequests for processing during a third time period, where the third timeperiod for processing is more than one hour after the first time periodbut before the second time period; during the third time period,receiving current vehicle location data for a plurality of ridesharingvehicles, wherein the current vehicle location data includes globalpositioning system (GPS) data generated by at least one GPS componentassociated with each of the plurality of ridesharing vehicles; duringthe third time period, processing the first request, the second request,and the vehicle location data to identify a specific ridesharing vehiclefor transporting both the first user and the second user; during thethird time period, calculating a ridesharing route for picking up thefirst user and the second user, wherein calculating the ridesharingroute includes determining pick-up locations for the first user and thesecond user that differ from the first starting point and the secondstarting point; after the third time period and before the second timeperiod, wirelessly transmitting to the first user and the second userthe respective pick-up locations; and after the third time period andbefore the second time period, wireless transmitting to the specificridesharing vehicle, the calculated route for picking up the first andsecond user during the second time period.

Consistent with other disclosed embodiments, non-transitorycomputer-readable storage media may store program instructions, whichare executed by at least one processing device and perform any of themethods described herein.

The foregoing general description and the following detailed descriptionare exemplary and explanatory only and are not restrictive of theclaims.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are incorporated in and constitute partof this disclosure, illustrate various example embodiments. In thedrawings:

FIG. 1 is a diagram illustrating an example ridesharing managementsystem, in accordance with some embodiments of the present disclosure.

FIG. 2 is a diagram illustrating the components of an example mobilecommunications device associated with a ridesharing management system,in accordance with some embodiments of the present disclosure.

FIG. 3 is a diagram illustrating the components of an exampleridesharing management server associated with a ridesharing managementsystem, in accordance with some embodiments of the present disclosure.

FIG. 4A and FIG. 4B are flowcharts of example processes for vehicleridesharing management, in accordance with some embodiments of thepresent disclosure.

FIG. 5 is a diagram of example timelines showing ridesharingarrangements, in accordance with some embodiments of the presentdisclosure.

FIG. 6 is an exemplary embodiment of a memory containing softwaremodules consistent with the present disclosure.

FIG. 7 is a schematic illustration of a mobile communications device fortransmitting information about passengers to be picked, according to anembodiment consistent with the present disclosure.

FIG. 8 is a flowchart of an exemplary process for counting a number ofpassengers entering a ridesharing vehicle.

FIG. 9 is an exemplary embodiment of a memory containing softwaremodules consistent with the present disclosure.

FIG. 10 is a schematic illustration of selection between a plurality ofcharging stations in response to an estimated charging completion timeand predicted demand, according to an embodiment consistent with thepresent disclosure

FIG. 11 is a flowchart of an exemplary process for distributing vehiclesin need of charge to charging stations based on predicted future demand.

FIG. 12 is an exemplary embodiment of a memory containing softwaremodules, in accordance with some embodiments of the present disclosure.

FIG. 13 is a schematic illustration of exemplary process for assigning afirst user to a first vehicle and a second user to a second vehiclebased on the ride requests, battery-charge data, and vehicle locationdata.

FIG. 14 is a flowchart of an exemplary process for managing a fleet ofpetrol and non-petrol ridesharing vehicles, in accordance with someembodiments of the present disclosure.

FIG. 15 is an exemplary embodiment of a memory containing softwaremodules, in accordance with some embodiments of the present disclosure.

FIG. 16 is a flowchart of an exemplary process for managing a fleet ofridesharing vehicles in accordance with some embodiments of the presentdisclosure.

FIG. 17 is a flowchart of an exemplary process for selecting a specificroute for a specific vehicle-for-hire, in accordance with someembodiments of the present disclosure.

FIG. 18 is a diagram of an example memory module for dropping offpassengers at a safe location, in accordance with some embodiments ofthe present disclosure.

FIG. 19 is a diagram illustrating hardware of an exemplary autonomousvehicle-for-hire, in accordance with some embodiments of the presentdisclosure.

FIG. 20A is a diagram illustrating an example process for automaticallyadjusting a drop-off location, in accordance with some embodiments ofthe present disclosure.

FIG. 20B is a diagram illustrating an example process for automaticallyadjusting a pick-up location, in accordance with some embodiments of thepresent disclosure.

FIG. 21 is an exemplary embodiment of a memory containing softwaremodules consistent with the present disclosure.

FIG. 22A is a diagram of an example timeline illustrating how theridesharing management system provides transportation services toon-demand users and to prescheduling users consistent with the presentdisclosure.

FIG. 22B and FIG. 22C are schematic illustrations of an example mapillustrating some of the events included in the example timeline of FIG.22A, according to disclosed embodiments.

FIG. 23 is a flowchart of an example process used by a ridesharingmanagement system to direct a ridesharing vehicle to pick up users thatprescheduled a rideshare.

DETAILED DESCRIPTION

The following detailed description refers to the accompanying drawings.Wherever possible, the same reference numbers are used in the drawingsand the following description to refer to the same or similar parts.While several illustrative embodiments are described herein,modifications, adaptations and other implementations are possible. Forexample, substitutions, additions or modifications may be made to thecomponents illustrated in the drawings, and the illustrative methodsdescribed herein may be modified by substituting, reordering, removing,or adding steps to the disclosed methods. Accordingly, the followingdetailed description is not limited to the disclosed embodiments andexamples. Instead, the proper scope is defined by the appended claims.

Disclosed embodiments of the present disclosure provide methods andsystems for vehicle ridesharing and vehicle ridesharing management. Theterm “vehicle” or “ridesharing vehicle” as used herein refers to anykind of vehicle (e.g., car, van, SUV, truck, bus, etc.) suitable forhuman transportation, such as providing ride services. In someembodiments, a vehicle may be a taxi. In some embodiments, a vehicle mayinclude an autonomous vehicle, wherein a control device integrated withthe vehicle or a management system separate from the vehicle may sendoperational instructions and guide the vehicle to designated pick-uplocations and drop-off locations. For the ease and conciseness ofdescription, some embodiments disclosed herein may simply refer to avehicle or a taxi as an example, which does not limit the scope of thedisclosed embodiments.

Consistent with some embodiments of the present disclosure, aridesharing management system may receive a first ride request from afirst user. The first ride request may include a starting point and adesired destination. The ridesharing management system may calculate afirst estimated pick-up time based on a current location of a vehiclethat is in the surrounding areas. After sending a confirmation with theestimated pick-up time, the ridesharing management system may then guidethe vehicle to a pick-up location for picking up the first rider. Thepick-up location may be a different location from the starting pointincluded in the first ride request. The system may also guide the firstuser to the pick-up location.

In some embodiments, the system may subsequently receive a second riderequest from a second user, for example, while the first user is stillin the vehicle. The second ride request may include a second startingpoint and a second desired destination. The system may calculate asecond estimated pick-up time, provide a second confirmation to thesecond rider, and guide the second rider to a second pick-up location.In some embodiments, the second pick-up location may be a differentlocation from the second starting point included in the second riderequest.

In some embodiments, the system may calculate the fares for each user,based on the solo ride portion for a corresponding user, and the sharedportion of the ride. For example, the system may offer a discount forthe shared portion of the ride. In some embodiments, the system may alsocalculate the fare amount for a particular user based on variousservice-related parameters such as user input regarding whether to usetoll roads, the walking distance between the starting point and thepick-up location, and the walking distance between the desireddestination and the drop-off location.

The embodiments herein further include computer-implemented methods,tangible non-transitory computer-readable mediums, and systems. Thecomputer-implemented methods can be executed, for example, by at leastone processor that receives instructions from a non-transitorycomputer-readable storage medium. Similarly, systems and devicesconsistent with the present disclosure can include at least oneprocessor and memory, and the memory can be a non-transitorycomputer-readable storage medium. As used herein, a “non-transitorycomputer-readable storage medium” refers to any type of physical memoryon which information or data readable by at least one processor can bestored. Examples include random access memory (RAM), read-only memory(ROM), volatile memory, nonvolatile memory, hard drives, CD ROMs, DVDs,flash drives, disks, and any other known physical storage medium.Singular terms, such as “memory” and “computer-readable storage medium,”can additionally refer to multiple structures, such a plurality ofmemories or computer-readable storage mediums. As referred to herein, a“memory” may comprise any type of computer-readable storage mediumunless otherwise specified. A computer-readable storage medium may storeinstructions for execution by at least one processor, includinginstructions for causing the processor to perform steps or stagesconsistent with an embodiment herein. Additionally, one or morecomputer-readable storage mediums may be used in implementing acomputer-implemented method. The term “computer-readable storage medium”should be understood to include tangible items and exclude carrier wavesand transient signals.

FIG. 1 is a diagram illustrating an example ridesharing managementsystem, in which various implementations as described herein may bepracticed, according to some embodiments of the present disclosure. Asshown in FIG. 1, ridesharing management system 100 includes one or moremobile communications devices 120A-120F (collectively referred to asmobile communications devices 120), a network 140, a ridesharingmanagement server 150, and a database 170. The plurality of mobilecommunications devices 120A-120F may further include a plurality of userdevices 120A-120C associated with users 130A-130C respectively, aplurality of driver devices 120D and 120E associated with drivers 130Dand 130E, and a driving-control device 120F associated with anautonomous vehicle 130F. Consistent with some embodiments of the presentdisclosure, ridesharing management server 150 may communicate withdriving-control device 120F to direct autonomous vehicle 130F to pick upand drop off users 130A-130C. In one example, autonomous vehiclescapable of detecting objects on the road and navigate to designatedlocations may be utilized for providing ridesharing services.

The components and arrangements shown in FIG. 1 are not intended tolimit the disclosed embodiments, as the system components used toimplement the disclosed processes and features can vary. For example,ridesharing management system 100 may include multiple ridesharingmanagement servers 150, and each ridesharing management server 150 mayhandle a certain category of ridesharing services, ridesharing servicesassociated with a certain category of service vehicles, or ridesharingservices in a specific geographical region, such that a plurality ofridesharing management servers 150 may collectively provide a dynamicand integrated ridesharing service system.

Network 140 may facilitate communications between user devices 120 andridesharing management server 150, for example, receiving ride requestsand other ride server related input from or sending confirmations touser devices, and sending ride service assignments to driver devices anddriving-control devices. Network 140 may be any type of networks thatprovides communications, exchanges information, and/or facilitates theexchange of information between ridesharing management server 150 anduser devices 120. For example, network 140 may be the Internet, a LocalArea Network, a cellular network, a public switched telephone network(“PSTN”), or other suitable connection(s) that enables ridesharingmanagement system 100 to send and receive information between thecomponents of ridesharing management system 100. Network 140 may supporta variety of messaging formats and may further support a variety ofservices and applications for user devices 120. For example, network 140may support navigation services for mobile communications devices 120,such as directing the users and service vehicles to pick-up or drop-offlocations.

Ridesharing management server 150 may be a system associated with acommunication service provider which provides a variety of data orservices, such as voice, messaging, real-time audio/video, to users,such as users 130A-130E. Ridesharing management server 150 may be acomputer-based system including computer system components, desktopcomputers, workstations, tablets, handheld mobile communicationsdevices, memory devices, and/or internal network(s) connecting thecomponents. Ridesharing management server 150 may be configured toreceive information from mobile communications devices 120 over network140, process the information, store the information, and/or transmitinformation to mobile communications devices 120 over network 140.

For example, in some embodiments, ridesharing management server 150 maybe configured to: receive ride requests from user devices 120A-120C,send ride confirmation and ride fare information to user devices120A-120C, and send ride service assignments (for example, includingpick-up and drop-off location information) to driver devices 120D and120E, and driving-control device 120F. Further, ridesharing managementserver 150 may further be configured to receive user input from userdevices 120A-120C as to various ride service parameters, such as walkingdistance to a pick-up location, maximum delay of arrival/detour, andmaximum number of subsequent pick-ups, etc. In some embodiments,ridesharing management server 150 may be further configured to:calculate ride fares based on a solo portion of a user's ride and ashared portion of the ride. Further, the ride fare calculation mayfurther be based on various ride service parameters set by the user,such as the walking distance involved in the ride, and user selectionregarding toll road usage, etc.

Database 170 may include one or more physical or virtual storagescoupled with ridesharing management server 150. Database 170 may beconfigured to store user account information (including registered useraccounts and driver accounts), corresponding user profiles such ascontact information, profile photos, and associated mobilecommunications device information. With respect to users, user accountinformation may further include ride history, service feedbacks,complaints, or comments. With respect to drivers, user accountinformation may further include number of ride service assignmentscompleted, ratings, and ride service history information. Database 170may further be configured to store various ride requests received fromuser devices 120A-120C and corresponding starting point and desireddestination information, user input regarding various serviceparameters, pick-up and drop-off locations, time of pick-up anddrop-off, ride fares, and user feedbacks, etc.

Database 170 may further include traffic data, maps, and toll roadinformation, which may be used for ridesharing service management.Traffic data may include historical traffic data and real-time trafficdata regarding a certain geographical region, and may be used to, forexample, calculate estimate pick-up and drop-off times, and determine anoptimal route for a particular ride. Real-time traffic data may bereceived from a real-time traffic monitoring system, which may beintegrated in or independent from ridesharing management system 100.Maps may include map information used for navigation purposes, forexample, for calculating potential routes and guiding the users to apick-off or drop-off location. Toll road information may include tollcharges regarding certain roads, and any change or updates thereof. Tollroad information may be used to calculate ride fares, for example, incases where the user permits use of toll roads.

The data stored in database 170 may be transmitted to ridesharingmanagement server 150 for accommodating ride requests. In someembodiments, database 170 may be stored in a cloud-based server (notshown) that is accessible by ridesharing management server 150 and/ormobile communications devices 120 through network 140. While database170 is illustrated as an external device connected to ridesharingmanagement server 150, database 170 may also reside within ridesharingmanagement server 150 as an internal component of ridesharing managementserver 150.

As shown in FIG. 1, users 130A-130E may include a plurality of users130A-130C, and a plurality of drivers 130D and 130E, who may communicatewith one another, and with ridesharing management server 150 usingvarious types of mobile communications devices 120. As an example, amobile communications device 120 may include a display such as atelevision, tablet, computer monitor, video conferencing console, orlaptop computer screen. A mobile communications device 120 may furtherinclude video/audio input devices such as a microphone, video camera,keyboard, web camera, or the like. For example, a mobile communicationsdevice 120 may include mobile devices such as a tablet or a smartphonehaving display and video/audio capture capabilities. A mobilecommunications device 120 may also include one or more softwareapplications that facilitate the mobile communications devices to engagein communications, such as IM, VoIP, video conferences. For example,user devices 130A-130C may send requests to ridesharing managementserver 150 and receive confirmations therefrom. Drivers 130D and 130Emay use their respective devices to receive ride service assignments andnavigation information from ridesharing management server 150 and maycontact the users with their respective devices 120D and 120E.

In some embodiments, a user may directly hail a vehicle by hand gestureor verbal communication, such as traditional street vehicle hailing. Insuch embodiments, once a driver accepts the request, the driver may thenuse his device to input the ride request information. Ridesharingmanagement server 150 may receive such request information, andaccordingly assign one or more additional ride service assignments tothe same vehicle, for example, subsequent e-hail ride requests receivedfrom other mobile communications devices 120 through network 140.

In some embodiments, driver devices 120D and 120E, and driving-controldevice 120F may be embodied in a vehicle control panel, as a part of thevehicle control system associated with a particular vehicle. Forexample, a traditional taxi company may install a drive device in alltaxi vehicles managed by the taxi company. In some embodiments, driverdevices 120D and 120E, and driving-control device 120F, may be furthercoupled with a payment device, such as a card reader installed as a partof the vehicle control panel or as a separate device associated with thevehicle. A user may then use the payment device as an alternativepayment mechanism. For example, a user who hails the taxi on the streetmay pay through the payment device, without using a user deviceproviding ridesharing service.

FIG. 2 is a diagram illustrating the components of an example mobilecommunications device 200 associated with a ridesharing managementsystem, such as system 100 as shown in FIG. 1, in accordance with someembodiments of the present disclosure. Mobile communications device 200may be used to implement computer programs, applications, methods,processes, or other software to perform embodiments described in thepresent disclosure, such as mobile communications devices 120A-120F. Forexample, user devices 120A-120C, driver devices 120D and 120E, anddriving-control device 120F may respectively be installed with a userside ridesharing application, and a corresponding driver sideridesharing application.

Mobile communications device 200 includes a memory interface 202, one ormore processors 204 such as data processors, image processors and/orcentral processing units, and a peripherals interface 206. Memoryinterface 202, one or more processors 204, and/or peripherals interface206 can be separate components or can be integrated in one or moreintegrated circuits. The various components in mobile communicationsdevice 200 may be coupled by one or more communication buses or signallines.

Sensors, devices, and subsystems can be coupled to peripherals interface206 to facilitate multiple functionalities. For example, a motion sensor210, a light sensor 212, and a proximity sensor 214 may be coupled toperipherals interface 206 to facilitate orientation, lighting, andproximity functions. Other sensors 216 may also be connected toperipherals interface 206, such as a positioning system (e.g., GPSreceiver), a temperature sensor, a biometric sensor, or other sensingdevice, to facilitate related functionalities. A GPS receiver may beintegrated with, or connected to, mobile communications device 200. Forexample, a GPS receiver may be included in mobile telephones, such assmartphone devices. GPS software may allow mobile telephones to use aninternal or external GPS receiver (e.g., connecting via a serial port orBluetooth). A camera subsystem 220 and an optical sensor 222, e.g., acharged coupled device (“CCD”) or a complementary metal-oxidesemiconductor (“CMOS”) optical sensor, may be used to facilitate camerafunctions, such as recording photographs and video clips.

Communication functions may be facilitated through one or morewireless/wired communication subsystems 224, which includes an Ethernetport, radio frequency receivers and transmitters and/or optical (e.g.,infrared) receivers and transmitters. The specific design andimplementation of wireless/wired communication subsystem 224 may dependon the communication network(s) over which mobile communications device200 is intended to operate. For example, in some embodiments, mobilecommunications device 200 may include wireless/wired communicationsubsystems 224 designed to operate over a GSM network, a GPRS network,an EDGE network, a Wi-Fi or WiMax network, and a Bluetooth® network.

An audio subsystem 226 may be coupled to a speaker 228 and a microphone230 to facilitate voice-enabled functions, such as voice recognition,voice replication, digital recording, and telephony functions.

I/O subsystem 240 may include touch screen controller 242 and/or otherinput controller(s) 244. Touch screen controller 242 may be coupled totouch screen 246. Touch screen 246 and touch screen controller 242 may,for example, detect contact and movement or break thereof using any of aplurality of touch sensitivity technologies, including but not limitedto capacitive, resistive, infrared, and surface acoustic wavetechnologies, as well as other proximity sensor arrays or other elementsfor determining one or more points of contact with touch screen 246.While touch screen 246 is shown in FIG. 2, I/O subsystem 240 may includea display screen (e.g., CRT or LCD) in place of touch screen 246.

Other input controller(s) 244 may be coupled to other input/controldevices 248, such as one or more buttons, rocker switches, thumb-wheel,infrared port, USB port, and/or a pointer device such as a stylus. Touchscreen 246 may, for example, also be used to implement virtual or softbuttons and/or a keyboard.

Memory interface 202 may be coupled to memory 250. Memory 250 includeshigh-speed random-access memory and/or non-volatile memory, such as oneor more magnetic disk storage devices, one or more optical storagedevices, and/or flash memory (e.g., NAND, NOR). Memory 250 may store anoperating system 252, such as DRAWN, RTXC, LINUX, iOS, UNIX, OS X,WINDOWS, or an embedded operating system such as VXWorkS. Operatingsystem 252 may include instructions for handling basic system servicesand for performing hardware dependent tasks. In some implementations,operating system 252 can be a kernel (e.g., UNIX kernel).

Memory 250 may also store communication instructions 254 to facilitatecommunicating with one or more additional devices, one or more computersand/or one or more servers. Memory 250 can include graphical userinterface instructions 256 to facilitate graphic user interfaceprocessing; sensor processing instructions 258 to facilitatesensor-related processing and functions; phone instructions 260 tofacilitate phone-related processes and functions; electronic messaginginstructions 262 to facilitate electronic-messaging related processesand functions; web browsing instructions 264 to facilitate webbrowsing-related processes and functions; media processing instructions266 to facilitate media processing-related processes and functions;GPS/navigation instructions 268 to facilitate GPS and navigation-relatedprocesses and instructions; camera instructions 270 to facilitatecamera-related processes and functions; and/or other softwareinstructions 272 to facilitate other processes and functions.

In some embodiments, communication instructions 254 may include softwareapplications to facilitate connection with ridesharing management server150 that handles vehicle ridesharing requests. Graphical user interfaceinstructions 256 may include a software program that facilitates a userassociated with the mobile communications device to receive messagesfrom ridesharing management server 150, provide user input, and so on.For example, a user may send ride requests and ride service parametersto ridesharing management server 150 and receive ridesharing proposalsand confirmation messages. A driver may receive ride service assignmentsfrom ridesharing management server 150, and provide ride service statusupdates.

Each of the above identified instructions and applications maycorrespond to a set of instructions for performing one or more functionsdescribed above. These instructions need not be implemented as separatesoftware programs, procedures, or modules. Memory 250 may includeadditional instructions or fewer instructions. Furthermore, variousfunctions of mobile communications device 200 may be implemented inhardware and/or in software, including in one or more signal processingand/or application specific integrated circuits.

FIG. 3 is a diagram illustrating the components of an example anautomated ridesharing dispatch system 300 that includes ridesharingmanagement server 150 associated with a ridesharing management system100, in accordance with some embodiments of the present disclosure.Ridesharing management server 150 may include a bus 302 (or othercommunication mechanism), which interconnects subsystems and componentsfor transferring information within ridesharing management server 150.

As shown in FIG. 3, automated ridesharing dispatch system 300 mayinclude one or more processors 310, one or more memories 320 storingprograms 330 including, for example, server app(s) 332, operating system334, and data 340, and a communications interface 360 (e.g., a modem,Ethernet card, or any other interface configured to exchange data with anetwork, such as network 140 in FIG. 1). Automated ridesharing dispatchsystem 300 may communicate with an external database 170 (which, forsome embodiments, may be included within ridesharing management server150). Automated ridesharing dispatch system 300 may include a singleserver (e.g., ridesharing management server 150) or may be configured asa distributed computer system including multiple servers, server farms,clouds, or computers that interoperate to perform one or more of theprocesses and functionalities associated with the disclosed embodiments.The term “cloud server” refers to a computer platform that providesservices via a network, such as the Internet. When ridesharingmanagement server 150 is a cloud server it may use virtual machines thatmay not correspond to individual hardware. Specifically, computationaland/or storage capabilities may be implemented by allocating appropriateportions of desirable computation/storage power from a scalablerepository, such as a data center or a distributed computingenvironment.

Processor 310 may be one or more processing devices configured toperform functions of the disclosed methods, such as a microprocessormanufactured by Intel™ or manufactured by AMD™. Processor 310 maycomprise a single core or multiple core processors executing parallelprocesses simultaneously. For example, processor 310 may be a singlecore processor configured with virtual processing technologies. Incertain embodiments, processor 310 may use logical processors tosimultaneously execute and control multiple processes. Processor 310 mayimplement virtual machine technologies, or other technologies to providethe ability to execute, control, run, manipulate, store, etc. multiplesoftware processes, applications, programs, etc. In some embodiments,processor 310 may include a multiple-core processor arrangement (e.g.,dual, quad core, etc.) configured to provide parallel processingfunctionalities to allow ridesharing management server 150 to executemultiple processes simultaneously. It is appreciated that other types ofprocessor arrangements could be implemented that provide for thecapabilities disclosed herein.

Memory 320 may be a volatile or non-volatile, magnetic, semiconductor,tape, optical, removable, non-removable, or other type of storage deviceor tangible or non-transitory computer-readable medium that stores oneor more program(s) 330 such as server apps 332 and operating system 334,and data 340. Common forms of non-transitory media include, for example,a flash drive, a flexible disk, hard disk, solid state drive, magnetictape, or any other magnetic data storage medium, a CD-ROM, any otheroptical data storage medium, any physical medium with patterns of holes,a RAM, a PROM, and EPROM, a FLASH-EPROM or any other flash memory,NVRAM, a cache, a register, any other memory chip or cartridge, andnetworked versions of the same.

Ridesharing management server 150 may include one or more storagedevices configured to store information used by processor 310 (or othercomponents) to perform certain functions related to the disclosedembodiments. For example, ridesharing management server 150 may includememory 320 that includes instructions to enable processor 310 to executeone or more applications, such as server apps 332, operating system 334,and any other type of application or software known to be available oncomputer systems. Alternatively or additionally, the instructions,application programs, etc., may be stored in an external database 170(which can also be internal to ridesharing management server 150) orexternal storage communicatively coupled with ridesharing managementserver 150 (not shown), such as one or more database or memoryaccessible over network 140.

Database 170 or other external storage may be a volatile ornon-volatile, magnetic, semiconductor, tape, optical, removable,non-removable, or other type of storage device or tangible ornon-transitory computer-readable medium. Memory 320 and database 170 mayinclude one or more memory devices that store data and instructions usedto perform one or more features of the disclosed embodiments. Memory 320and database 170 may also include any combination of one or moredatabases controlled by memory controller devices (e.g., server(s),etc.) or software, such as document management systems, Microsoft SQLdatabases, SharePoint databases, Oracle™ databases, Sybase™ databases,or other relational databases.

In some embodiments, ridesharing management server 150 may becommunicatively connected to one or more remote memory devices (e.g.,remote databases (not shown)) through network 140 or a differentnetwork. The remote memory devices can be configured to storeinformation that ridesharing management server 150 can access and/ormanage. By way of example, the remote memory devices may includedocument management systems, Microsoft SQL database, SharePointdatabases, Oracle™ databases, Sybase™ databases, or other relationaldatabases. Systems and methods consistent with disclosed embodiments,however, are not limited to separate databases or even to the use of adatabase.

Programs 330 may include one or more software modules causing processor310 to perform one or more functions of the disclosed embodiments.Moreover, processor 310 may execute one or more programs locatedremotely from one or more components of the ridesharing managementsystem 100. For example, ridesharing management server 150 may accessone or more remote programs that, when executed, perform functionsrelated to disclosed embodiments.

In the presently described embodiment, server app(s) 332 may causeprocessor 310 to perform one or more functions of the disclosed methods.For example, devices associated with users, drivers and autonomousvehicles may respectively be installed with user applications forvehicle ridesharing services, and driver applications for vehicleridesharing services. Further, a mobile communications device may beinstalled with both the driver applications and the user applications,for uses in corresponding situations.

In some embodiments, other components of ridesharing management system100 may be configured to perform one or more functions of the disclosedmethods. For example, mobile communications devices 120 may beconfigured to calculate estimate pick-up and drop-off times based on acertain ride request, and may be configured to calculate estimate ridefares. As another example, mobile communications devices 120 may furtherbe configured to provide navigation service, and location service, suchas directing the user to a particular pick-up or drop-off location, andproviding information about a current location of the respective user orvehicle to ridesharing management server 150.

In some embodiments, program(s) 330 may include operating system 334performing operating system functions when executed by one or moreprocessors such as processor 310. By way of example, operating system334 may include Microsoft Windows™, Unix™, Linux™, Apple™ operatingsystems, Personal Digital Assistant (PDA) type operating systems, suchas Apple iOS, Google Android, Blackberry OS, Microsoft CE™, or othertypes of operating systems. Accordingly, the disclosed embodiments mayoperate and function with computer systems running any type of operatingsystem 334. Ridesharing management server 150 may also include softwarethat, when executed by a processor, provides communications with network140 through communications interface 360 and/or a direct connection toone or more mobile communications devices 120. Specifically,communications interface 360 may be configured to receive ride requests(e.g., from user devices 120A-120C) headed to differing destinations andreceive indications of the current locations of the ridesharing vehicles(e.g., from driver devices 120D and 120E or driving-control device120F). In one example, communications interface 360 may be configured tocontinuously or periodically receive current vehicle location data forthe plurality of ridesharing vehicles that are part of ridesharingmanagement system 100. The current vehicle location data may includeglobal positioning system (GPS) data generated by at least one GPScomponent of a mobile communications device 120 associated with eachridesharing vehicle.

In some embodiments, data 340 may include, for example, profiles ofusers, such as user profiles or driver profiles. Data 340 may furtherinclude ride requests from a plurality of users, user ride history anddriver service record, and communications between a driver and a userregarding a particular ride request. In some embodiments, data 340 mayfurther include traffic data, toll road information, and navigationinformation, which may be used for handling and accommodating riderequests.

Automated ridesharing dispatch system 300 may also include one or moreI/O devices 350 having one or more interfaces for receiving signals orinput from devices and providing signals or output to one or moredevices that allow data to be received and/or transmitted by automatedridesharing dispatch system 300. For example, automated ridesharingdispatch system 300 may include interface components for interfacingwith one or more input devices, such as one or more keyboards, mousedevices, and the like, that enable automated ridesharing dispatch system300 to receive input from an operator or administrator (not shown).

FIGS. 4A and 4B are flowcharts of example processes 410 and 420 forvehicle ridesharing management, in accordance with some embodiments ofthe present disclosure. In one embodiment, all of the steps of process400 may be performed by a ridesharing management server, such asridesharing management server 150 described above with reference toFIGS. 1 and 3. Alternatively, at least some of the steps of process 400may be performed by a mobile communications device, such as the mobilecommunications devices 120 described above with reference to FIGS. 1 and2. In the following description, reference is made to certain componentsof FIGS. 1-3 for purposes of illustration. It will be appreciated,however, that other implementations are possible and that othercomponents may be used to implement example methods disclosed herein.

At step 411, ridesharing management server 150 may receive a first riderequest from a first wireless communication of a first user, forexample, a request from user 130A sent through user device 120A. Thefirst ride request may include a first starting point and a firstdesired destination. A ride request may refer to a request from a userneeding transportation service from a certain location to another. Astarting point may refer to a current location of the user, as input bythe user through an input device of an associated user device, or asdetermined by a location service application installed on the userdevice. In some embodiments, the starting point may be a locationdifferent from the current location of the user, for example, a locationwhere the user will subsequently arrive at (e.g., entrance of abuilding). A desired destination may refer to a location where the userrequests to be taken to.

In some embodiments, the actual pick-up location and the actual drop-offlocation may be different from the starting point and the desireddestination. For example, the pick-up location may be of a certaindistance from the starting point, where the user may be directed to forpick-up. By encouraging the user to walk to a pick-up location nearby,consistent with some embodiments, the vehicle may more easily andquickly locate the user without causing an excessive detour or anexcessive delay for users who are in the vehicle. Similarly, byencouraging the user to walk from a drop-off location different from butwithin a certain distance from the desired destination, the vehicle maybe able to accommodate subsequent pick-ups, or arrive at the subsequentpick-up locations more quickly. The vehicle ridesharing servicemanagement system may provide incentives or rewards for the user who arewilling to walk a certain distance. For example, the ridesharingmanagement system may offer certain discounts based on the number anddistances of the walks involved in a particular ride. Alternatively, theridesharing management system may offer ride credits corresponding tothe number and distance of the walks undertaken by the user during hisrides. The user may use the credits for subsequent ride payment, orredeem the credit for money, free rides, or other rewards. Further,advantages of such embodiments may include more efficient vehicle useand management, more user flexibility, and less air pollution associatedwith vehicle use.

In some embodiments, prior to or after the user sends a ride request toridesharing management server 150, the user may further input rideservice parameters through, for example, a settings component providedon a user interface. Ride service parameters refer to user preferenceparameters regarding a vehicle ridesharing service, for example, amaximum walking distance from the starting point to a pick-up location,a maximum walking distance from a drop-off location to a desireddestination, a total maximum walking distance involved in a ride, amaximum number of subsequent pick-ups, maximum delay of arrival/detourincurred by subsequent pick-ups during a ride, and a selection whetherto permit toll road usage during the ride, etc.

Ride service parameters may be transmitted to ridesharing managementserver 150 for processing the request and assignment of an availablevehicle based on the ride service parameters. For example, a riderequest may be associated with a maximum walking distance of 300 metersfrom a starting point to a pick-up location. When assigning an availablevehicle to pick up the user, ridesharing management server 150 mayinclude in the assignment an assigned pick-up location within 300 metersor less of the starting point. Similarly, a ride request may beassociated with a maximum walking distance of 0.5 mile from a drop-offlocation to a desired destination. When assigning an available vehicleto pick up the user, ridesharing management server 150 may include inthe assignment an assigned drop-off location within 0.5 mile or lessfrom the desired destination.

For requests associated with a maximum total walking distance of onemile during the ride, when assigning an available vehicle to pick up theuser, ridesharing management server 150 may include in the assignment anassigned pick-up location and an assigned drop-off location, a total ofa distance from the starting point to the assigned pick-up location anda distance from the assigned drop-off location to a desired destinationmay be equal to or less than one mile.

In the above examples, the values regarding the walking distances areonly exemplary. Other embodiments consistent with the present disclosuremay use different options of the distances and may provide a list ofoptions. The distances may further be measured in different units, forexample, miles, meters, kilometers, blocks, and feet, etc., which arenot limited by the disclosed embodiments herein. In some embodiments,the distance may further be represented by an average walking time froma certain location to another, based on average walking speed, forexample, ten minutes, five minutes, etc.

With respect to parameters regarding subsequent pick-ups, such as amaximum number of subsequent pick-ups, and maximum delay of arrivalincurred by subsequent pick-ups, ridesharing management server 150 mayassign subsequent pick-ups accordingly, without exceeding the parametersset by the user. For example, a ride request may be associated with amaximum number of two subsequent pick-ups during the ride. Ridesharingmanagement server 150 may monitor the service status of the vehicleassigned to pick up the user, and refrain from assigning a thirdsubsequent pick-up before the vehicle arrives at a drop-off location fordropping off the user. As another example, for a ride request associatedwith a maximum delay of arrival of ten minutes, when assigningsubsequent ride requests, ridesharing management server 150 maycalculate an estimated delay that may occur to the user if the samevehicle was to undertake the subsequent ride request. If the estimateddelay that may occur to the user is more than ten minutes, ridesharingmanagement server 150 may assign the subsequent ride request to otheravailable vehicles.

In some embodiments, the user may also input selection of toll roadusage through the associated user device, to allow or disallow use oftoll roads. Ridesharing management server 150 may then take the user'sselection into account when assigning an available vehicle foraccommodating the ride request, determining travel route, andcalculating ride fare for the user. For example, ridesharing managementserver 150 may adjust the ride fare amount for a corresponding userbased on the toll roads selection input and toll charges involved. Foranother example, if a first user does not permit toll road usage, beforeany subsequent pick-ups during the ride, ridesharing management server150 may send a route to an assigned vehicle that does not include tollroads. For another example, if a subsequent user sharing the ridepermits usage of toll road, ridesharing management server 150 may notcharge the first user for any overlap portion of the ride where tollroads are used, change the route to include toll roads after the firstuser is dropped off, or assign the second user to a ridesharing vehiclewith users that permit toll road usage.

In some embodiments, the ride request information may also be input fromthe driver device, for example, driver device 120D, or from a deviceassociated with the vehicle. In the case of street hailing, where theuser hails a vehicle on the street without using a vehicle ridesharingservice application on a mobile communications device, the driver, forexample, driver 130D, may input information such as the startingpoint/pick-up information and destination information through driverdevice 120D, which may then be transmitted to ridesharing managementserver 150.

At step 413, ridesharing management server 150 may calculate anestimated pick-up time, for example, based on a current location of anassigned vehicle and the first starting point included in the first riderequest. An estimated pick-up time may refer to a time period before anassigned vehicle arrives at a pick-up location for picking up the user.

The assigned vehicle may refer to the vehicle that is assigned toundertake the first ride request, for example, a taxi in a taxi fleet,one of a plurality of vehicles managed by a transportation servicesystem, or a plurality of vehicles owned by a plurality of owners andused to provide ridesharing services. The pick-up location may be thesame as the starting point, or an assigned pick-up location associatedwith the starting point.

The estimated pick-up time may be determined based on a distance betweena current location of the assigned vehicle and the pick-up location, andan estimate speed of traveling along the route between the twolocations. The current location of the assigned vehicle may bedetermined by a location service application installed on a driverdevice, a driving-control device, or by a location determinationcomponent in the ridesharing management system 100, which may be a partof or separate from ridesharing management server 150. In someembodiments, the estimated pick-up time may further be determined basedon historical or real-time traffic data, and a route currently followedby the vehicle.

In some embodiments, process 410 may further include locating one or aplurality of potential available vehicles and selecting an assignedvehicle therefrom. For example, potential available vehicles may includevacant vehicles in the surrounding areas of the first starting point,and vehicles heading to a location close to the first starting point forassigned pick-ups or drop-offs. Ridesharing management server 150 mayfilter potential available vehicles by ride service parameters set bythe users who are inside the vehicle, for example, removing occupiedvehicles where a user inside the vehicle does not permit subsequentpick-ups, or occupied vehicles where the user requires a minimal delay.In some embodiments, ridesharing management server 150 may filterpotential assignment vehicles by choosing a vehicle that would involveminimal walking of the user or walking without the need of crossing thestreet. In some embodiments, ridesharing management server 150 mayfurther filter potential assignment vehicles by choosing a vehicle thatwould involve minimal detour for the vehicle to arrive at the pick-uplocation. In some embodiments, the assigned vehicle may be selected byapplying multiple filter criteria, or by applying multiple filtercriteria in a certain order.

In some embodiments, the pick-up location may be an assigned pick-uplocation different from the first starting point, for example, half ablock or further away from the first starting point. Ridesharingmanagement server 150 may assign a pick-up location based on rideservice parameters set by the first user, as described above at step411. Ridesharing management server 150 may further assign a pick-uplocation which is along a main street where an assigned vehicle caneasily locate, or a location which would not require an assign vehicleto take a U-turn. In cases where there are one or more other users inthe vehicle, ridesharing management server 150 may assign a pick-uplocation close to the vehicle's next assigned drop-off, or on the sideof a street where the vehicle will soon go through. In some embodiments,ridesharing management server 150 may adjust selection of the pick-uplocation based on filtering results of potential assignment vehicles, orvice versa. The two selection processes may complement each other toreach one or more optimal combinations.

In some embodiments, where there are multiple potential assignmentvehicles, each with a corresponding potential pick-up location, anestimated pick-up time may be respectively calculated corresponding toeach of the potential assignment vehicles. Ridesharing management server150 may then choose the vehicle with the shortest estimated pick-up timeto be the assigned vehicle.

At step 415, ridesharing management server 150 may send a first messageto a user device associated with the first user, which is, in thisexample, user device 120A. The first message may be configured to causean indication of the calculated first estimated pick-up time to appearon a display of user device 120A. The message may appear in differentformats, for example, a text message including the estimated pick-uptime, an audio message, or an image, the specific implementation ofwhich are not limited by the disclosed embodiments herein.

In one embodiment, the message includes a confirmation that theridesharing request is accepted. If ridesharing management server 150assigns a pick-up location different from the starting point, themessage may further cause the display of an indication of the assignedpick-up location. Ridesharing management server 150 may further providea navigation option which may be displayed on a user interface. Aselection of the navigation option may then provide walking directionsthe user to the assigned pick-up location for pick-up. The message mayfurther cause a display of an indication of an estimated walkingdistance from the starting point to the assigned pick-up location. Inaddition, the message may include an estimated walking distance from theassigned drop-off location to the desired destination. The assigneddrop-off location may be a location close to the desired destination,within the maximum walking distance parameters set by the first user.For example, the drop-off location may be at a location half a blockaway or further from the desired destination and may be along a mainstreet where the vehicle may easily locate and access. For anotherexample, the drop-off location may be determined based on a routetowards the next pick-up location, such that the vehicle may easily dropoff the first user on its way to the next pick-up location, therebyavoiding an extra detour.

In another embodiment, the message may include one or more proposalsassociated with different vehicles. Each proposal may includeinformation about the proposed pick-up location. The information aboutthe proposed pick-up location may include the distance from the user tothe proposed pick-up location. Each proposal may include a price of theride associated with the type of the ride, and an estimation of apick-up time. The estimate may be presented as a range. In one example,each proposal may include different pick-up locations, different prices,and/or different estimations of a pick-up time. According to thisembodiment, step 415 may also include receiving a proposal selectionreflective of a selected pick-up vehicle and sending an addition messagethat includes information about the selected vehicle, and the driverassociated with the vehicle. For example, the vehicle information mayinclude the license plate number, brand, color, and/or model of thevehicle. The driver information may include a name, nickname, profilephoto, ratings, number of previous rides, and/or contact information ofthe driver. The message may further include a contact option allowingthe user to contact the driver, for example, a “contact the driver”button, which the user may select to initiate a communication sessionwith the driver.

At step 417, ridesharing management server 150 may guide the assignedvehicle to the first pick-up location for picking up the first user. Forexample, ridesharing management server 150 may transmit directioninformation to the driver device associated with the assigned vehicle,for example, driver device 120D or driving-control device 120F. In someembodiments, a navigation component of the driver device, or thedriving-control device may perform the step of guiding the vehicle tothe first pick-up location. Correspondingly, ridesharing managementserver 150, or a navigation component of the user device 120A, may guidethe user to the first pick-up location, in cases where the pick-uplocation is an assigned pick-location different from the first startingpoint. For example, for autonomous vehicles used for ridesharingservices, such as autonomous vehicle 130F as shown in FIG. 1, thevehicle itself may be capable of using a variety of techniques to detectits surroundings, identify feasible paths, and navigate without directhuman input.

In some embodiments, once the vehicle is assigned to pick up the user,ridesharing management server 150 may assign a communication channel forthe driver associated with the assigned vehicle to communicate with theuser, for example, a masked phone number. In some embodiments, a userinterface of a driver device, such as driver device 120D, may include anoption to send notification messages to the user, for example, apre-defined message button of “I'm here.” Once the vehicle arrives atthe pick-up location, the driver may click the message button to sendthe message to the user. This way, the driver may not need to dial outor type a message in order to notify the user of the vehicle's arrival,reducing driver distraction and associated safety hazards.

At step 419, ridesharing management server 150 may receive a second riderequest from a second user. In some embodiments, the second user requestmay be a street hailing request received directly by the vehicle whilethe first user is still inside, namely, before dropping off the firstuser. The vehicle may then undertake the second ride request, if thefirst user permits subsequent pick-ups. In some embodiments, the driverof the vehicle may input the second ride request information through adriver device, for example, driver device 120D associated with driver130D. The input may inform ridesharing management server 150 that thevehicle has undertaken a second ride request or may further include thepick-up location and destination information of the second user.Ridesharing management server 150 may then accordingly determine whetherto assign additional pick-ups to the same vehicle and may further senddirection information guiding the vehicle to the second user'sdestination.

In some embodiments, the second ride request may be received byridesharing management server 150 from a second wireless mobilecommunications device, for example, user device 120B associated withuser 130B as shown in FIG. 1. The second ride request may furtherinclude a second starting point, and a second desired destination.Ridesharing management server 150 may then assign a corresponding rideservice to an available vehicle, which may be the vehicle that haspicked up the first user, before dropping off the first user. Inprocessing the second ride request, the example process 420 as shown inFIG. 4B may be performed.

At step 422, ridesharing management server 150 may calculate a secondestimated pick-up time, for example, based on a second current locationof the vehicle and the second starting point. The second estimatedpick-up time may refer to an estimated time period before the vehiclearrives at a second pick-up location for picking up the second user. Thesecond pick-up location may be an assigned pick-up location differentfrom, but associated with, the second starting point. Assignment of thesecond pick-up location may include similar steps as described abovewith reference to FIG. 4A, details of which are not repeated herein.

At step 424, ridesharing management server 150 may send a second messageto the second wireless mobile communication device, which is user device120B in this example. The second message may be configured to cause anindication of the calculated second estimated pick-up time to appear ona display of the second wireless mobile communication device. Asdescribed above with reference to FIG. 4A, the message may appear indifferent formats, and may further cause a display of multiple proposalswith multiple options for the second pick-up location, walking distance,walking directions from the second starting point to the second pick-uplocation, etc., the details of which are not repeated herein.

In some embodiments, ridesharing management server 150 may set thesecond pick-up location at substantially the same location as the firstpick-up location, for example, half a block away, or 100 meters awayfrom the first pick-up location. This way, the vehicle may pick up bothusers at about the same time at substantially the same location, furtherimproving service efficiency. In some embodiments, ridesharingmanagement server 150 may set the second pick-up location at asubstantially the same location as the first drop-off location, whereinthe vehicle may drop off the first user, and pick up the second user atabout the same time, without extra travelling. Further, in someembodiments, the second drop-off location may be set at substantiallythe same location as the first drop off location, such that the vehiclemay drop off multiple users at the same time.

In some embodiments, ridesharing management server 150 may set the firstpick-up location to substantially differ from the first starting point,and the second pick-up location to substantially differ from the secondstarting point, for example, to ensure both pick-up locations are alongthe same side of the same street where the vehicle may go through.Ridesharing management server 150 may then send respective directions tothe first user device and the second user device, to guide the users tothe respective pick-up locations.

In some embodiments, ridesharing management server 150 may set the firstpick-up location at substantially the same as the first starting pointand set the second pick-up location to substantially differ from thesecond starting point. For example, the selection of the pick-uplocations may be made such that the first pick-up location and thesecond pick-up location are close to one another, both pick-up locationsare along the same street, or the second pick-up location is close tothe first drop-off location. Ridesharing management server 150 may thensend respective directions to the first user device and the second userdevice, to guide the users to the respective pick-up locations.

At step 426, ridesharing management server 150 may guide the vehicle toa second pick-up location for picking up the second user. As describedabove with reference to FIG. 4A, this step may also be performed by anavigation component of the driver's device (e.g., driver device 120D ordriving-control device 120F associated with autonomous vehicle 130F).

In some embodiments, ridesharing management server 150 may change thefirst drop-off location after receiving the second ride request, and thechange may be made without pre-approval of the first user. The firstdrop-off location refers to a location for dropping off the first user.As described above with reference to FIG. 4A, the first drop-offlocation may be the same as the first desired destination, or at alocation different from the first desired destination.

For example, the second pick-up location may be set at a location closeto the first desired destination, included in the first ride request.When assigning the second ride request to the vehicle, ridesharingmanagement server 150 may change the first drop-off location to alocation closer to or at the first desired destination, thus reducingthe walking distance for the first user to arrive at his desireddestination. For another example, the first drop-off location may bechanged to a location where the first user does not need to cross thestreet to arrive at his desired destination, without causing orincreasing detour for the vehicle to arrive at the second pick-uplocation.

In some embodiments, ridesharing management system 100 may subsequentlyreceive a plurality of subsequent ride requests. These additional riderequests may either be received by ridesharing management server 150 andassigned to the vehicles or received by the vehicles in the form ofstreet hailing. Steps described above with reference to FIGS. 4A and 4Bmay similarly be used to process the third ride request.

For example, ridesharing management server 150 may receive a third riderequest from a third user device, for example, user device 120Cassociated with user 130C, as shown in FIG. 1. Ridesharing managementserver 150 may process the request and assign the request to the vehiclewhile at least one of a first user and a second user is still in thevehicle. The third ride request may further include a third startingpoint and a third desired destination. Ridesharing management server 150may calculate a third estimated pick-up time and send a confirmation toa user's device (e.g., user device 120C). Ridesharing management server150 may transmit direction and route information to the driver's deviceassociated with the vehicle (e.g., driver device 120D as shown in FIG.1), to guide the vehicle to pick up and drop off user 130C.

As described above with reference to FIGS. 4A and 4B, processing ofsubsequent ride requests may take into account the ride serviceparameters set by the users whose requests have previously been receivedand assigned. For example, if both the first user and the second userare still in the vehicle, and one of them has set a maximum delay ofarrival, ridesharing management server 150 may not assign the thirdrequest to the same vehicle if such assignment would cause a delaylonger than the set value. For example, if the first user has set amaximum delay of arrival of 10 minutes, ridesharing management server150 may calculate an estimated time period it takes for the vehicle topick up (and/or drop off) the third user before dropping off the firstuser. If the estimated time would cause a total delay of arrival for thefirst user to exceed 10 minutes, ridesharing management server 150 maytherefore assign the third ride request to another vehicle. For anotherexample, if the second user has set a maximum number of one co-rider andthe second user will be dropped off earlier than the first user,ridesharing management server 150 may not assign to the same vehicle, assuch assignment may cause violation of the parameter (maximum number ofone co-rider) set by the second user.

FIG. 5 is a diagram of three example timelines showing ridesharingarrangements, in accordance with some embodiments of the presentdisclosure. As shown in example timelines 510, 520, and 530, for aparticular assigned vehicle undertaking a first ride request from afirst user and a second ride request from a second user, the order ofpick-ups and drop-offs for the second user may vary. For example,ridesharing management server 150 may receive a plurality of riderequests, design an optimal path and pick-up/drop-off order for aparticular assigned vehicle undertaking multiple requests, and assignadditional pick-ups as the vehicle completes a part of or all of theride requests. For example, as shown in example timeline 510, a vehiclemay receive a second ride request after picking up the first user anddrop off the first user before dropping off the second user. Acorresponding shared ride portion may be the portion of ride between thepick-up of the second user and drop-off of the first user. As shown inexample timeline 520, the vehicle may receive a second ride requestafter picking up the first user and drop off the second user beforedropping off the first user. A corresponding shared ride portion may bethe portion of ride between the pick-up of the second user and drop-offthe second user. As another example, as shown in example timeline 530,the vehicle may receive the first ride request and the second riderequest before any pick-up. The vehicle may then pick up the second userbefore picking up the first user and drop off the second user beforedropping off the first user. A corresponding shared ride portion may bethe portion of ride between pick-up of the first user and drop-off ofthe second user. Depending on the order of pick-ups and drop-offs, theridesharing management server may then determine a corresponding sharedride portion, and calculate ride fare for each user based on, forexample, the shared portion, solo portion of each user, and/or otherfactors such as the ride service parameters set by each user.

Counting a Number of Passengers Entering a Ridesharing Vehicle

In some embodiments of the present disclosure, one or more ridesharingvehicles may participate in a ridesharing fleet. The ridesharing fleetmay seek to confirm that the number of people entering a ridesharingvehicle matches the number of people that requested the transportationby a vehicle of the ridesharing feet. Conventional fleets may notaccount for the number of passengers entering a vehicle. For example, adiscrepancy may arise when the number of passengers entering the vehicledoes not match the number of passengers indicated in a ride request. Aridesharing management system may not be able to accurately anticipatethe capacity of the vehicle to accept additional ride requests becauseof this discrepancy. Accordingly, embodiments of the present disclosuremay count the number of passengers entering a ridesharing vehicle. Theseand other features of presently disclosed embodiments are discussed inmore detail below.

FIG. 6 depicts an embodiment of memory 600 for counting a number ofpassengers entering a ridesharing vehicle consistent with the presentdisclosure. The ridesharing vehicle (e.g., autonomous vehicle 130F) mayinclude a vehicle body, a communications interface within the vehiclebody for wirelessly communicating with a remote server configured toelectronically receive shared-ride requests from a plurality of users,at least one sensor associated with the vehicle body and configured todetect entry (and exit) of passengers from the ridesharing vehicle, andat least one processor within the vehicle body, the at least oneprocessor being programmed to execute instructions to perform one ormore operations. The ridesharing vehicle may include memory 600configured to store a plurality of modules and may be executable by atleast one processor to perform various methods and processes disclosedherein. Further, it should be noted that memory 600 may store more orfewer modules than those shown in FIG. 6, depending onimplementation-specific considerations.

As illustrated in FIG. 6, memory 600 may store software instructions toexecute a data collection module 610, a passenger identification module620, a remedial action module 630, a database access module 640, and mayinclude a database 650. Data collection module 610 may include softwareinstruction for receiving, via a communications interface, informationabout passengers to be picked up. Data collection module 610 may alsoinclude software instruction for receiving, from at least one sensor, anumber of passengers actually picked up at a pickup location. Passengeridentification module 620 may include software instruction fordetermining an identification of passengers. The determination may bebased on image data wirelessly transmitted from an image sensor to aremote server or data collection module 610. Remedial action module 630may include software instructions for comparing the actual number ofpassengers picked up at the pick-up location with a scheduled number ofpassengers and routing the ridesharing vehicle based on a desireddestination of an unscheduled passenger and initiating a remedial actionwhen a difference exists between the scheduled number of passengers andthe actual number of passengers as detected by the at least one sensor.Database access module 640 may include software instruction executableto interact with database 650, to store and/or receive information(e.g., geographical maps associated with a geographical area in which avehicle is operating, current traffic information of a geographicalarea, passenger identification information, passenger image data, etc.).

Data collection module 610 may include software instructions forreceiving, via a communications interface, information about passengersto be picked up. Data collection module 610 may receive the passengerinformation via communications interface 360. The received informationmay include a pick-up location and a scheduled number of passengersexpected to be picked up at the pick-up location. In one embodiment, theinformation about the passengers to be picked up may include details ofat least two shared-ride requests associated with the scheduled numberof passengers expected to be picked up at the pick-up location. In thisembodiment, the at least one processor may be further configuredidentify which of the at least two shared-ride requests is associatedwith the difference exists between the scheduled number of passengersand the actual number of passengers. For example, the details of atleast two shared-ride requests associated with scheduled number ofpassengers expected to be picked up may include the number of passengersper ride-booking assigned to the pick-up location. Specifically, thenumber of passengers per ride-booking may be important when a user wantsto book a ride for a group of passengers, but the request books onepassenger. In this case, the actual number of passengers associated withthe corresponding booking is different. Therefore, the ridesharingvehicle may need to check whether the submitted number of passengersassociated with a booking in the ride-share request is equal to theactual number of passengers. In one case, there may be two bookings ofpassengers with the same pick-up point which are to be picked-up by thesame ridesharing vehicle. In this case, counting the number ofpassengers at the pickup point may not be enough; that is, theridesharing vehicle may need to count the actual number of passengersassociated with each ride-booking and if there is an inconsistency atthe booking level. The at least one processor may identify which of theat least two shared-ride requests is associated with the differencebased on image processing, voice processing, feedback from the user'scommunication device or any other means. In addition, the pick-uplocation may be received as a geographical coordinate information,street address, or a region prescribed by a geofence. The schedulednumber of passengers may be indicated as an integer. Each integer mayrepresent a unit of vehicle capacity required in a ridesharing vehiclenecessary to comply with the received information.

Additionally, or alternatively, data collection module 610 may receive,via the communications interface, an indication of a scheduledpassenger's luggage capable of impacting capacity of the ridesharingvehicle. Data collection module 610 may receive information pertainingto a number of units of luggage and/or an estimated size/weight of eachunit of luggage. In some embodiments, the units of luggage may includeone or more suitcases, bicycles, musical instruments, car seats, etc.Data collection module 610 may use information pertaining to the numberof units of luggage and/or estimated size/weight to estimate and impacton the capacity on the ridesharing vehicle. For example, data collectionmodule 610 may determine that received information includes anindication of two large suitcases with a one passenger may reduce theridesharing vehicle's capacity by three. Thus, data collection module610 may determine that a ridesharing vehicle with a capacity for threeis necessary to fulfill the ride request of the passenger. Processor 310may identify a first ridesharing vehicle in the ridesharing fleet withthis capacity and assign the passenger to the first ridesharing vehicle.

Further, data collection module 610 may receive, via the communicationinterface, information about a drop-off location and a number ofpassengers scheduled to departure at the drop-off location. A pluralityof drop-off locations may be indicated for each of a plurality ofpassengers included in the number of passengers. Alternatively, a singledrop-off location may be indicated for the number of passengers as asingle unit.

In some embodiments, the information received by data collection module610 may be part of a ride requests from one or more users requestingservices from ridesharing management server. A ride request may betransmitted to ridesharing management server 150 and may includeinformation such as a pick-up location, a drop-off location, andidentity of the user, a rating of the user, a current user location, anumber of passengers to be picked-up, etc. Information associated with aride request may be received, for example, from a mobile communicationdevice (e.g. a smartphone, tablet, wearable device, etc.) associated(e.g. located in the passenger cabin) with a user. For example, user130A may transmit a ride request from user device 120A over network 140.Network 140 may be configured to transmit data to communicationsinterface 340 for processing by processor 310.

For example, FIG. 7 illustrates a schematic illustration of a mobilecommunications device for transmitting information about passengers tobe picked, according to an embodiment consistent with the presentdisclosure. Ride request 700 may include information inputted by a userand may be transmitted to processor 310 via a communication interface.Information included in ride request 700 may be received by datacollection module 610. Ride request 700 may include location information710 pertaining to a pick-up location information and desired destinationinformation, a number of passengers expected to be picked-up 720, and anumber of pieces of luggage 730. The number of passengers expected to bepick-up 720 and the number of pieces of luggage 730 may be summed toarrive at the total capacity required 750 in a ridesharing vehicle. Insome embodiments, the total capacity required 740 may be calculated bymobile communications device or entered by a user. In some embodiments,ride request 700 may also be configured to enable a user to transmitimage data 750. Image data 750 may include one or more images associatedwith passenger identification information.

Returning to FIG. 6, data collection module 610 may also includesoftware instructions for receiving, from at least one sensor, a numberof passengers actually picked up at a pickup location. The at least onesensor may include at least one of an infrared sensor, a volumetricsensor, a weight sensor, a proximity sensor, and an image sensor. Insome embodiments, the at least one sensor may include a combination ofone or more sensors. For example, the at least one sensor may include acombination of an image sensor and a weight sensor or a combination ofan image sensor, volumetric sensor, and an infrared sensor. The at leastone sensor may be configured to detect the number of passengers actuallypicked up at the pickup location and transmit data to data collectionmodule 610 indicating the number of passengers based on the detection.In some embodiments, data collection module 610 may also, after arrivingat the pick-up location, receive from the at least one sensor anindication of passenger's luggage actually picked up at the pick-uplocation.

Data collection module 610 may also include software instruction forreceiving, via the communications interface, information about adrop-off location and a number of passengers scheduled to departure atthe drop-off location. Information about a drop-off location and anumber of passengers scheduled to departure may be received by datacollection module 610 based on user input via ride request 700. Datacollection module 610 may also after arriving at the drop-off location,receive from the at least one sensor a number of passengers actuallydeparted at the drop-off location. Information about a number ofpassengers actually departed at the drop-off location may be received bydata collection module 610 based on one or more signals detected by theat least one sensor.

Passenger identification module 620 may facilitate determination ofidentities of passengers using the at least one sensor, wherein the atleast one sensor includes an image sensor, and wherein facilitatingdetermination includes comparing image data from the image sensor withimage-related data wirelessly received. The image-related data may bewirelessly received from data collection module 610, from or one or moredevices associated with an operator of the ridesharing vehicle, or froma database associate with ridesharing management server 150. Forexample, passenger identification module 620 may compare the wirelesslyreceived image-related to data included in a database of passengersregistered with the ridesharing service with image data of one or morepassengers picked up at the pick-up location. In other embodiments, theimage-related data may include the passenger's facial signature andimage of the passenger's profile associated with one or more socialmedia accounts, or an image of the passenger stored in a database with apassenger profile. The passenger profile may be generated duringpassenger registration with the ridesharing service.

In some embodiments, passenger identification module 620 may cause theat least one sensor to capture an image of the one or more passengersand derive image data of the one or more passengers from the capturedimage. The at least one sensor may include an image sensor, andpassenger identification module 620 may include software instructionsfor causing data from the image sensor to be wirelessly transmitted to aremote server for passenger identity confirmation at the remote server.Identification confirmation at a remote serve may enable personal dataidentifying a passenger to be secure.

Passenger identification module 620 may also include softwareinstructions for receiving, via the communications interface,identifying information from a mobile communications device of apassenger and to thereby confirm an identity of the passenger based ondata obtained from the mobile communications device. The ridesharingvehicle may be equipped with a short-range transmitter configured torequest the identifying information from the passenger's mobile deviceor other communications device, such as a tablet, smart watch, etc. Insome embodiments, passenger identification module 620 may be configuredto automatically retrieve the identifying information from the mobilecommunications device of a passenger. In other embodiment, a user mayprovide an indication to the mobile communication device authorizingidentifying information to be obtained by passenger identificationmodule 620.

Remedial action module 630 may include software instructions forcomparing the actual number of passengers picked up at the pick-uplocation with a scheduled number of passengers. Based on informationreceived from passenger identification module 620 indicating a number ofpassengers actually picked up at the pick-up location and informationreceived from data collection module 610 indicating a number ofpassengers expected to be picked up at the pick-up location, remedialaction module 630 may determine a difference between the two numbers.The difference may represent the comparison, or discrepancy, between theactual quantity and the expected quantity.

Alternatively, or additionally, remedial action module 630 may includesoftware instructions for comparing the actual passenger's luggagepicked up at the pick-up location with the scheduled passenger's luggageassociated with the pick-up location the comparison. For example,remedial action module 630 may determine that one or more pieces ofluggage that was not expected based on information received by datacollection module 610 was actually picked up at the pick-up location.Accordingly, remedial action module 630 may determine that a ridesharingvehicle capacity was different from expected. In some embodiments,remedial action module 630 may compare the actual number of passengersdeparted at the drop-off location with the scheduled number ofpassengers associated with the drop-off location. For example, remedialaction module 630 may determine that passengers expected to depart at adrop-off location did not actually depart from the ridesharing vehicleas expected. Thus, the actual number of passengers departing from a dropoff location may be different from an expected, or scheduled number ofpassengers associated with the drop off location. Remedial action module630 may determine, based on results of the comparison, that an actualridesharing vehicle capacity deviates from an expected ridesharingvehicle capacity, based on information received by data collectionmodule 610 and from the at least one sensor.

Remedial action module 630 may include software instructions forinitiating a remedial action when a difference exists between thescheduled number of passengers and the actual number of passengers asdetected by the at least one sensor. The remedial action may providenotification to an operator or one or more passengers of the ridesharingvehicle that a difference exists between the scheduled, or expected,number of passengers and the actual number of passengers detected by theat least one sensor. The remedial action may include providing at leastone of audio or visual feedback within the ridesharing vehicle. In someembodiment, the remedial action may include haptic feedback.

Remedial action module 630 may include software instructions forwirelessly transmitting an indication of the difference to the remoteserver. The indication of the difference may include one or more signalsrepresenting data associated with the difference. The indication of thedifference may include an indication of whether a difference is detectedby the at least one sensor, a magnitude of the difference, whether theactual number of passengers exceeds or is less than the scheduled numberof passengers, and/or a current ridesharing vehicle capacity. The remoteserver may analyze the indication to determine a remedial action to betaken.

In some embodiments, transmitting the indication may enable the remoteserver to take into account the current number of passengers in thevehicle when making future assignments of passengers to the ridesharingvehicle. Alternatively, or additionally, remedial action module 630 mayinitiate a remedial action for identifying an unscheduled passenger anddetermining a desired destination of the unscheduled passenger. Forexample, remedial action module 630 may transmit data to a user deviceassociated with an identified passenger requesting information relatedto an unscheduled passenger. The transmitted data may include a requestthat the unscheduled passenger to communication with ridesharingmanagement server 150, that a scheduled passenger enter informationrelated to the unscheduled passenger. In other embodiments the data maybe transmitted to a device associated with an operator of theridesharing vehicle. Based on the transmitted data requestinginformation related to the unscheduled passenger, ridesharing managementserver 150 may receive information regarding a desired destination ofthe unscheduled passenger and/or identifying information.

Remedial action module 630 may also include software instructions forinitiating a remedial action, and the remedial action may include afirst action if the scheduled number of passengers is less than theactual number of passengers as detected by the at least one sensor, andthe remedial action includes a second action if the scheduled number ofpassengers is greater than the actual number of passengers as detectedby the at least one sensor, the first action being different from thesecond action. That is, based on whether results of the comparison ofthe scheduled number of passengers is greater than or less than theactual number of passengers detected by the at least one sensor,remedial action module 630 may determine which of a plurality ofremedial action should be initiated. For example, based on adetermination that a current ridesharing vehicle capacity is at apredetermined ridesharing vehicle capacity due to an unscheduledpassenger being picked-up at a pick-up location, remedial action module630 may initiate a remedial action for assigning a scheduled passengerpreviously assigned to a first ridesharing vehicle to a secondridesharing vehicle. In other embodiments, remedial action module 630may initiate a remedial action for assigning an additional passenger toa first ridesharing vehicle based on a determination that a scheduledpassenger was not picked-up at a pick-up location, or erroneousinformation regarding a scheduled passenger's luggage impacting theridesharing vehicle's capacity.

Still in other embodiments, remedial action module 630 may initiate aremedial action when a difference exists between the scheduledpassenger's luggage received via the wireless connection and the actualpassenger's luggage as detected by the at least one sensor. For example,in some embodiments, a passenger may indicate in a ride request arequest to reserve capacity for a suitcase. After arriving at thepick-up location, data collection module 610 may determine that thepassenger requires ridesharing vehicle capacity for four suitcases.Remedial action module 630 may thereafter reassign the scheduledpassenger to a different ridesharing vehicle and cause a cost estimateof the ride request to be adjusted. Alternatively, or additionally,remedial action module 630 may initiate a remedial action when adifference exists between the number of passengers scheduled todeparture at the drop-off location and the actual number of passengersdeparted at the drop-off location. For example, data collection module610 may determine that one or more passenger did not depart from thevehicle as a desired destination indicated in a ride request. Remedialaction module 630 may provide a notice and/or reminder to the passenger,send a text message, cause an adjustment to a price of the ride, thuscharging the passenger for the additional time/distance commuted.Remedial action module 630 may thus enable the remote server to takeinto account the current number of passengers in the vehicle when makingfuture assignments of passengers to the ridesharing vehicle based on anestimated and actual ridesharing vehicle capacity.

As illustrated in FIG. 6, database 650 may be configured to store anytype of information associated with modules 610-640, depending onimplementation specific considerations. For example, in embodiments inwhich battery-charge module 620 and/or charging station module 630 isconfigured to access one or more prior-stored maps of geographical areasfor determining a route, database 650 may store the geographical maps.In other embodiments where charging station module 630 is configured toaccess one or more listings of charging stations, database 650 may storelocations, hours of operation, and/or charging capacity for eachcharging station. Still, in other embodiments, database 650 may includeinformation related to a charging capacity of each of the plurality ofcharging stations to accept additional vehicles, and for ride requestswith pick-up location in a vicinity of the specific electrically poweredvehicle-for-hire in need of the charge, at least one processor may beconfigured to assign the specific electrically-powered vehicle-for-hireto pick up a user based on a proximity of a drop-off location to acharging station and a capacity of that charging station to accept thespecific electrically-powered vehicle for-hire. Location module 610,battery-charge module 620, and charging station module 630 may accessdatabase for communication by way of data access module 640.

Modules 610-640 may be implemented in software, hardware, firmware, orany combination of software, hardware or firmware. For example, if themodules are implemented in software, they may be stored in memory 250.However, in some embodiments, any one or more of modules 610-640 anddata associated with database 650 may, for example, be stored inprocessor 204 and/or executed on a device associated with ridesharingmanagement system 100. Modules 610-640 may be configured to interactwith each other and/or other modules of memory 250 to perform functionsconsistent with disclosed embodiments.

FIG. 8 illustrates a flowchart showing exemplary process 800 forcounting a number of passengers entering a ridesharing vehicle,consistent with disclosed embodiments. In one embodiment, the steps ofprocess 800 may be performed by a vehicle management server, such asridesharing management server 150 described above with reference toFIGS. 1 and 3. Alternatively, at least some of the steps of process 800may be performed by a mobile communications device, such as the mobilecommunications devices 120 described above with reference to FIGS. 1 and2. In the following description, reference is made to certain componentsof FIGS. 1-3 for purposes of illustration. It will be appreciated,however, that other implementations are possible and that othercomponents may be used to implement example methods disclosed herein.

At step 810, data collection module 610 may receive information aboutpassengers to be picked up. The information may be received via acommunication interface within a vehicle body for wirelesslycommunicating with a remote server configured to electronically receiveshared-ride requests from a plurality of users. The received informationmay include one or more of a pick-up location, a scheduled number ofpassengers expected to be picked up at the pick-up location, anindication of scheduled passenger's luggage capable of impactingcapacity of the ridesharing vehicle, and/or information about a drop-offlocation and a number of passengers scheduled to departure at thedrop-off location. In some embodiments, data collection module 610 maydetermine a pick-up location and a drop-off location, the determinedpick-up location being at a location other than but in proximity to thestarting point and the determined drop-off location being at a locationother than but in proximity to the desired destination. In someembodiments, the information may receive from one or more of a deviceassociated with a passenger, a device associated with the ridesharingvehicle, and/or a remote server.

At step 820, data collection module 610 may receive a number ofpassengers actually picked up at a pick-up location. The number ofpassengers actually picked up at the pick-up location may be receivedfrom at least one sensor. The at least one sensor may include at leastone of an infrared sensor, a volumetric sensor, a weight sensor, aproximity sensor, and an image sensor. The number of passengers actuallypicked up may be received after a ridesharing vehicle arrived as thepick-up location. After arriving at the pick-up location, process 800may also include receiving from the at least one sensor an indication ofpassenger's luggage actually picked up at the pick-up location andreceiving from the at least one sensor a number of passengers actuallydeparted at the drop-off location.

At step 830, remedial action module 630 may compare the actual number ofpassengers picked up at the pick-up location with a scheduled number ofpassengers. As explained above, the comparison may include an analysisof data received by data collection module 610 and associated with aride request and data received after arriving at a pick-up location.

At step 840, remedial action module 630 may initiate a remedial actionwhen a difference exists between the scheduled number of passengers andthe actual number of passengers. The remedial action may includeproviding at least one of audio or visual feedback within the vehicle.The remedial action may include wirelessly transmitting an indication ofthe difference to the remote server. In some embodiment, as explainedabove, the remedial action may include identifying an unscheduledpassenger and determining a desired destination of the unscheduledpassenger. The remedial action may include a first action if thescheduled number of passengers is less than the actual number ofpassengers as detected by the at least one sensor, and the remedialaction may include a second action if the scheduled number of passengersis greater than the actual number of passengers as detected by the atleast one sensor, the first action being different from the secondaction.

Process 800 may include additional steps. For example, process 800 mayinclude facilitating determination of identities of passengers,receiving an indication of scheduled passenger's luggage capable ofimpacting capacity of the ridesharing vehicle, receiving, via thecommunications interface, information about a drop-off location and anumber of passengers scheduled to departure at the drop-off location. Insome embodiments, facilitating determination may include one or more ofcomparing image data from the image sensor with image-related datawirelessly received, causing data from the image sensor to be wirelesslytransmitted to a remote server for passenger identity confirmation atthe remote server, and/or receive, via the communications interface,identifying information from a mobile communications device of apassenger and to thereby confirm an identity of the passenger based ondata obtained from the mobile communications device.

Distributing Vehicles in Need of Charge to Charging Stations Based onPredicted Future Demand

In some embodiments of the present disclosure, one or moreelectrically-powered vehicles may participate in a fleet of vehicles forhire. The ridesharing fleet systems configured to manage the fleet ofvehicles may seek reliable ways to manage the charging of theelectrically-powered vehicles and a demand for ridesharing vehicles in ageographical area. Conventional ridesharing management systems may relyon discretion of one or more operators of the one or more electricallypowered vehicles to manage a charging schedule for eachelectrically-powered vehicle independently. However, when relying onindividual discretion, conventional ridesharing management systems maybe unable to distribute vehicles in need of charge to charging stationsbased on predicted future demand. Accordingly, embodiments of thepresent disclosure may distribute vehicles in need of charge to chargingstations based on a predicted future demand. These and other features ofpresently disclosed embodiments are discussed in more detail below.

FIG. 9 depicts an embodiment of memory module 250 for distributingvehicles in need of charge to charging stations based on a predictedfuture demand consistent with the present disclosure. Memory 250 maystore a plurality of modules and may be executable by at least oneprocessor to perform various methods and processes disclosed herein.Further, it should be noted that memory 250 may store more or fewermodules than those shown in FIG. 9, depending on implementation-specificconsiderations.

As illustrated in FIG. 9, memory 250 may store software instructions toexecute a battery-charge module 910, a location module 920, a chargingmodule 930, a ride request module 940, a database access module 950, andmay include a database 960. Battery-charge module 910 may includesoftware instruction for receiving locations of ridesharing vehiclesfrom one or more sources. Location module 920 may include softwareinstruction for receiving battery-charge levels of ridesharing vehiclesfrom one or more sources. Charging module 930 may include softwareinstruction to determine a predicted demand for ridesharing requestsand/or an estimated charging completion time. Ride request module 940may include software instruction to direct a specific vehicle to aselected charging station. Database access module 950 may includesoftware instruction executable to interact with database 960, to storeand/or receive information (e.g., geographical maps associated with ageographical area in which a vehicle is operating, current trafficinformation of a geographical area, historical data for past demand in ageographical area, etc.).

Battery-charge module 910 may include software instructions forreceiving current battery-charge data for a plurality of electricalvehicles. The current battery-charge data may be reflective of aduration and/or distance that each electric vehicle may operate beforerecharging. The duration and/or distance that each electric vehicle mayoperate before recharging may be based on an estimated duration and/ordistance until depletion of a battery charging the vehicle and/or basedon a remaining charge level of the battery. The current battery-chargedata may be captured by a power sensor in the vehicle configured todetermine the current charge level of the battery. The power sensor maytransmit the data to a remote server over a wireless channel or tovehicle routing module to select a charging station, based on thecurrent battery charge level. The power sensor may be configured tocontinuously monitor and transmit data related to the current batterycharge level. The power sensor may also monitor the current batterycharge level and transmit data when the charge level is less than apredetermined threshold level.

In some embodiments, the current battery-charge data may be indicativeof a driving duration and/or distance in which each electrically-poweredridesharing vehicle can operate before charging. For example,battery-charge module 910 may determine the driving duration and/ordistance based on the current charge level of the battery and one ormore known characteristics of the vehicle. In such an example,battery-charge module 910 may convert the charge level (e.g., measuredin volts or amperes) to a duration and/or distance using a conversionfactor associated with the year, make, and module of the vehicle and/orusing a conversion factor determined from historical data associatedwith the vehicle. Alternatively, the vehicle may perform the conversionand send the driving duration and/or distance to battery-charge module620.

Additionally or alternatively, battery-charge module 910 may estimatethe driving duration using real-time traffic data along a current routeof the vehicle. Additionally or alternatively, battery-charge module 910may estimate the driving duration and/or distance using terrain data,such as elevation changes, along a current route of the vehicle.Accordingly, the driving duration may be dynamically re-determinedwhenever the current route is changed. Additionally or alternatively,battery-charge module 910 may estimate the driving duration and/ordistance using driver-performances data indicative of driveracceleration and deceleration rates. For example, the driving durationand/or distance may be increased for a driver that accelerates anddecelerates within a first range and may be decreased for a driver thataccelerates and decelerates within a second, higher range.

Battery-charge module 910 may also include software instructions foridentifying, from the current battery-charge data, a specific electricvehicle traveling in the geographic area and in need of a charge. Thespecific electric vehicle may be identified based on one or morecharacteristics of the current battery-charge data. For example,battery-charge module 910 may analyze current battery-charge-data anddetermine that when the current battery-charge data is less that apredetermined threshold, the vehicle is in need of charge. In someembodiments, battery-charge module 910 may analyze currentbattery-charge-data and determine, when the driving duration and/ordistance is less that a predetermined threshold, that the vehicle in isneed of charge.

Location module 920 may include software instructions for receivingcurrent vehicle location data for a specific electric vehicle. In someembodiments, the current vehicle location data may include globalpositioning system (GPS) data generated by at least one GPS componentassociated with the specific electric vehicle. Additionally oralternatively, location module 920 may receive other locationinformation, such as cell tower triangulation data, Wi-Fi or othersignal strength data, or any other combination of location information.

Charging module 930 may include software instruction for determiningbattery charging stations within a geographic area. The geographic areamay include a current location of at least one of the vehicles. Chargingmodule 930 may also determine a number of charging points in eachcharging station. The locations and charging points may be stored indatabase 950 and accessed by charging module 930.

Ride request module 940 may include software instructions fordetermining, using historical data, predicted demand for ridesharingrequests in at least one area proximate to at least one of the pluralityof charging stations. In some embodiments, the predicted demand forridesharing requests may be based on historical data associated with apast demand for ridesharing requests in the at least one area proximateto the at least one of the plurality of charging stations. The predicteddemand may be associated with a number of ride requests received byridesharing management server within a predetermined period of time. Inother embodiments, the predicted demand may be associated with a time ofday, day of the week, month of the year, expected weather and/or anevent being hosted in the at least one area proximate to at least one ofthe plurality of charging stations.

Ride request module 940 may also include software instructions for basedon an estimated charging completion time and the predicted demand,selecting a charging station for the specific electric vehicle. Theselected charging station may be a charging station other than acharging station closest to a current location of the specific electricvehicle. In some embodiments, ride request module 940 may manage aschedule for charging at the selected charging station based on thepredicted demand. For example, in some embodiments, ride request module940 may manage the schedule such that during a period of high predicteddemand, one or more vehicles are charged to 40% of charging capacity. Inother embodiments, ride request module 940 may manage the schedule suchthat during a period of low predicted demand, one or more vehicles arecharged to 100% of the charging capacity. Additionally or alternatively,ride request module 940 may manage the schedule such thatarrival/departure of vehicles to and from a selected charging stationare staggered so that a first vehicle arrives for charging as a secondvehicle completes charging.

In some embodiments, ride request module 940 may reassign at least oneuser scheduled to be picked up by the specific electric vehicle to adifferent ridesharing vehicle when the estimated charging completiontime is after the desired time to shorten the estimated chargingcompletion time. For example, ride request module 940 may determine thatavoiding picking up a scheduled user may increase a likelihood that thespecific electric vehicle is able to complete charging and thus enablethe specific electric vehicle to be available by the desired time. Forexample, ride request module 940 may determine that the assignment of auser to the specific electric vehicle delay the estimated chargingcompletion time to noon. Ride request module 940 may compare theestimated charging completion time with a desired time prior to noon andreassign the user to another ridesharing vehicle. The reassignment mayenable a specific electric vehicle to complete charging prior at thedesired time.

In some embodiments, ride request module 940 may change at least onedrop-off location of at least one passenger currently riding thespecific electric vehicle when the estimated charging completion time isafter the desired time to shorten the estimated charging completiontime. For example, ride request module 940 may determine that a scheduledrop-off location may decrease a likelihood that the specific electricvehicle is able to complete charging by the desired time. Accordingly,ride request module may change, or ask the passenger to change, thedrop-off location. The changed drop-off location may enable the specificelectric vehicle to be available by the desired time.

In some embodiments, an estimated charging completion time may bedetermined based on one or more of an expected battery usage whentraveling to the selected charging station, information about chargingcapacities of the specific electric vehicle, and/or a desired charginglevel prior to returning the specific vehicle to service. For example,in some embodiments, charging module 930 may access a memory that storesinformation about charging capacities of each of the plurality ofelectric vehicles, and determine the estimated charging completion timefor the specific electric vehicle based on an expected battery usagewhen traveling to the selected charging station, the information aboutcharging capacities of the specific electric vehicle, and a desiredcharging level prior to returning the specific vehicle to service.

In some embodiments, an estimated charging completion time may bedetermined based on an expected battery usage when traveling to theselected charging station. The expected battery usage may be based on acurrent location of the specific electric vehicle, a location of theselected charging station, and one or more characteristics of a drivingroute from the current location of the specific electric vehicle to thelocation of the selected charging station. In some embodiments, riderequest module 940 may transmit information to battery-charge module 910for estimated battery usage when traveling to the selected chargingstation. In some embodiments, battery-charge module 910 may analyze thecharacteristics of the driving route to estimate the expected batteryusage. For example, characteristics of the driving route may includeinformation received based on map data including information about aterrain of the geographic area. Ride request module 940 may select acharging station that may be accessed along a route with fewer elevationchanges than one or more non-selected charging stations. Battery-chargemodule 910 may thereafter analyze characteristics of the terrain of thegeographical data to estimate an expected battery usage. In otherembodiments, characteristics of the driving route may includeinformation received based on traffic data or speed limit data. Thetraffic data and speed limit data may be based on historical dataassociated with the driving route, a time of day, and/or a computedestimated time of arrival.

In some embodiments, an estimated charging completion time may bedetermined based on information about charging capacities of thespecific electric vehicle based on obtained current occupancy data forthe selected charging station, wherein the obtained current occupancydata includes a current capacity utilization for each charging point inthe selected charging station and current battery-charge data for eachelectric vehicle located at the selected charging station. Based on anumber of charging points in each charging station and the currentcapacity utilization for each charging point, charging module 930 maydetermine whether a number of open charging points at each station, ifany. For example, charging module 930 may determine that the selectedcharging station includes four charging point. Charging module 930 mayfurther determine that all charging point are currently occupied and/oran estimate of whether any charging points will become available withina predetermined period of time.

Additionally, or alternatively, charging module 930 may determine anestimated time at which occupied charging points will become available.For example, charging module 930 may determine the estimated chargingcompletion time based on the current charge level of anelectrically-powered ridesharing vehicle located at a charging stationand one or more known characteristics of the charging point used by thevehicle and/or the vehicle. In such an example, charging module 930 mayconvert a remaining charge requirement (e.g., measured in volts oramperes) to an estimated time using a conversion factor associated withthe year, make, and module of the vehicle and/or using a conversionfactor determined from historical data associated with the vehicle.Additionally or alternatively, charging module 930 may convert aremaining charge requirement (e.g., measured in volts or amperes) to anestimated charging completion time using a conversion factor associatedwith a model of the charging point and/or using a conversion factordetermined from historical data associated with the charging point. Inany of the above embodiments, the charging station may perform theconversion and send the estimated time to charging module 930.

In some embodiments, an estimated charging completion time may bedetermined based on a desired charging level prior to returning thespecific vehicle to service. In some embodiments, the desired charginglevel may be based on the predicted demand and an availability of othervehicles in the fleet of ridesharing vehicles. For example, ride requestmodule 940 may determine that in a geographical region with a predicteddemand exceeding an estimated capability of other available vehicle inthe fleet of ridesharing vehicles, the desired charging level prior toreturning to service may be 30%. In other embodiments, ride requestmodule may determine, based on a low predicted demand and ampleavailability of other vehicles in the fleet of ridesharing vehicle, thata desired charging level prior to returning to service may be 100%. Inother embodiment, ride request module 940 may determine a desired timefor the specific vehicle to return to service based on the predicteddemand and a location of the selected charging station, compare thedesired time to the estimated charging completion time. For example,ride request module may determine that an estimated charging completiontime will elapse subsequent to the desired time for the specific vehicleto return to service. Ride request module 940 may determine based on adriving duration and/or distance that charging can be delayed for thespecific electric vehicle.

Ride request module 940 may further include software instructions fordirecting the specific electric vehicle to the selected chargingstation. For example, in response to selecting the charging station,ride request module 930 may determine a route for the specific electricvehicle that terminates at the selected charging station.

In some embodiments, the specific electric vehicle may direct thespecific electric vehicle from a drop-off location of a last passengerto the selected charging station. In some embodiments, the specificelectric vehicle may be manually-driven and may include a handhelddevice associated with the driver of the vehicle and configured toreceive routing instructions from ridesharing management server 150. Thespecific electric vehicle may also include an autonomous vehicle and mayinclude a vehicle controller configured to receive routing instructionsfrom ridesharing management server 150. In such embodiment, directingthe specific electric vehicle from the drop-off location may includetransmitting to the specific electric vehicle a specific driving routeto the selected charging station. Transmitting to the specific electricvehicle may include transmitting to a vehicle controller configured toreceive routing instructions and/or a device associated with an operatorof the specific electric vehicle.

In any of the embodiments discussed above, ride request module 940 mayidentify at least two driving routes from the drop-off location of thelast passenger to the selected charging station and to select a drivingroute that includes less elevation changes. In some embodiments, theselected driving route may include a greater travel distance but withless elevation changes compared to an alternative driving route. Thedriving route may be selected based on a determination that the selecteddriving route is likely to conserve more energy than a shorter drivingdistance with more elevation changes. In other embodiments, the drivingroute may be selected to minimize travel time.

Based on this information and information received from battery-chargemodule 910, location module 920, and charging station module 930, riderequest module 940 may select a charging station for a specificelectrically-powered ridesharing vehicle. In some embodiments, theselected charging station may be other than a charging station closestto a current location of the specific electrically-powered ridesharing.Accordingly, charging station module 630 may apply an optimizationalgorithm such that the driving duration and/or distance received ordetermined by battery-charge module 620 functions as a hard constraintbut that the other variables are optimized within the constraint. Forexample, the algorithm may optimize the estimated time to plug-in basedon distances between a current location of the specific vehicle and thecharging stations as well as the current occupancy of those stations.

As illustrated in FIG. 9, database 960 may be configured to store anytype of information associated with modules 910-950, depending onimplementation specific considerations. For example, in embodiments inwhich battery-charge module 920 and/or charging station module 930 isconfigured to access one or more prior-stored maps of geographical areasfor determining a route, database 950 may store the geographical maps.In other embodiments where charging station module 930 is configured toaccess one or more listings of charging stations, database 950 may storelocations, hours of operation, and/or charging capacity for eachcharging station. Still, in other embodiments, database 950 may includeinformation related to a charging capacity of each of the plurality ofcharging stations to accept additional vehicles, and historical demandin a vicinity of the specific electrical vehicle for rides. At least oneprocessor may be configured to make an intermediate stop at the specificcharging station while at least one passenger remains in the specificelectric vehicle, and to direct the at least one passenger to transferto another ridesharing. Additionally, the least one processor may informa driver of the another ridesharing vehicle about the at least onepassenger before the specific electric vehicle arrives to the chargingstation. Location module 910, battery-charge module 920, charging module930, and ride request module 940 may access database 960 forcommunication by way of data access module 950.

Modules 910-950 may be implemented in software, hardware, firmware, orany combination of software, hardware or firmware. For example, if themodules are implemented in software, they may be stored in memory 250.However, in some embodiments, any one or more of modules 910-950 anddata associated with database 960 may, for example, be stored inprocessor 204 and/or executed on a device associated with ridesharingmanagement system 100. Modules 910-950 may be configured to interactwith each other and/or other modules of memory 250 to perform functionsconsistent with disclosed embodiments.

FIG. 10 illustrates an example of selection between a plurality ofcharging stations in response to an estimated charging completion timeand predicted demand. As depicted in FIG. 10, a specific electricvehicle 1010 may be located in a geographic area associated with aplurality of charging stations. In the example of FIG. 10, threecharging stations (1020 a, 1020 b, and 1020 c) are located in ageographic area. Ride management server 150 may determine a predicteddemand for area 1030, representing at least one area proximate to atleast one of the plurality of charging station. The predicted demand mayalso include a desired time that electric vehicle 1010 is needed in area1030. Ride management server 150 may also determine that an estimatecharging completing time for each of charging stations 1020 a and 1020 bif selected, is after the desired time. Accordingly, based on thedriving duration and/or distance of electric vehicle 1010, chargingcapacities at the plurality of charging stations and a predicted demandat area 1030, ride management server 150 may direct electric vehicle1010 to charging station 1020 c, instead of charging station 1020 awhich may be closes to a current location of electric vehicle 1010. Asexplained above, additional variables may be considered in making theselection, such as historical data associated with demand forridesharing vehicles in the geographic area, an elevation, anavailability of other vehicle in the fleet of ridesharing vehicles, orthe like.

FIG. 11 illustrates a flowchart showing exemplary process 1100 fordirecting an electric vehicle to a charging station, consistent withdisclosed embodiments. In one embodiment, the steps of process 1100 maybe performed by a vehicle management server, such as ridesharingmanagement server 150 described above with reference to FIGS. 1 and 3.Alternatively, at least some of the steps of process 1100 may beperformed by a mobile communications device, such as the mobilecommunications devices 120 described above with reference to FIGS. 1 and2. In the following description, reference is made to certain componentsof FIGS. 1-3 for purposes of illustration. It will be appreciated,however, that other implementations are possible and that othercomponents may be used to implement example methods disclosed herein.

At step 1110, battery-charge module 910 may receive currentbattery-charge data for a plurality of electric vehicles. As explainedabove, the current battery-charge data may be indicative of a drivingduration and/or distance that each electric vehicle can operate beforerecharging. In some embodiments, battery-charge module 910 may estimatethe driving duration and/or distance. For example, battery-charge module910 may receive real-time traffic data and estimate a driving durationand/or distance in which a specific electric vehicle can operate beforecharging based on the current battery-charge data and the real-timetraffic data. Additionally or alternatively, battery-charge module 910may access map data including information about a terrain of thegeographic area and determine a driving duration and/or distance thateach electric vehicle can operate before charging before rechargingbased on the current battery-charge data and elevation changes expectedalong a scheduled route of the specific electrically-powered ridesharingvehicle.

At step 1120, location module 920 may identify a specific electricvehicle traveling in the geographic area and in need of a charge. Thespecific electric vehicle may be identified based on the battery-chargedata. The battery-charge data may be reflective of a current batterycharge level for a vehicle within the geographical area. Thegeographical area may be prescribed by a geofence boundary, a zip code,of a predetermined distance from a central point.

At step 1130, location module 920 may receive current vehicle locationdata for the specific electric vehicle. As explained above, the currentvehicle location data may include global positioning system (GPS) datagenerated by at least one GPS component associated with the specificelectric vehicle.

At step 1140, ride request module 940 may determine predicted demand forridesharing requests in at least one area proximate at least one of theplurality of charging stations. The predicted demand may be based onusing historical data. The historical data may be associated with pastdemand for ridesharing vehicles in the geographic area and used todetermine predicted passenger-demand.

At step 1150, ride request module 940 may select a charging station forthe specific electric vehicle, wherein the selected charging station isother than a charging station closest to a current location of thespecific electric vehicle. The charging station may be selected based onan estimated charging completion time and/or the predicted demand and/oravailability of other vehicles in the fleet. The predicted demand may bedetermined at step 1140. In some embodiments, ride request module 940may access a memory that stores information about charging capacities ofeach of the plurality of electric vehicles. In some embodiments, riderequest module 940 may determine the estimated charging completion timefor the specific electric vehicle based on an expected battery usagewhen traveling to the selected charging station, the information aboutcharging capacities of the specific electric vehicle, and a desiredcharging level prior to returning the specific vehicle to service. Theexpected battery usage maybe based on the current location of thespecific electric vehicle, a location of the selected charging station,and characteristics of a driving route from the current location of thespecific electric vehicle to the location of the selected chargingstation. The desired charging level prior to return of the specificvehicle to service may be based on the predicted demand and anavailability of other vehicles in the fleet of ridesharing vehicles. Theexpected charging completion time at the selected charging stationfurther may be based on obtained current occupancy data for the selectedcharging station. The obtained current occupancy data may include acurrent capacity utilization for each charging point in the selectedcharging station and current battery-charge data for each electricvehicle located at the selected charging station

At step 1160, ride request module 940 may direct the specific electricvehicle to the selected charging station. Ride request module 940 mayalso to manage a schedule for charging at the selected charging stationbased on the predicted demand. In some embodiments, ride request module940 may direct the specific electric vehicle from a drop-off location ofa last passenger to the selected charging station. Directing thespecific electric vehicle from the drop-off location includestransmitting to the specific electric vehicle a specific driving routeto the selected charging station. Ride request module 940 select adriving route that includes less elevation changes than an alternativedriving route.

Process 1100 may include additional steps. For example, process 1100 mayinclude one or more of determining a desired time for the specificvehicle to return to service based on the predicted demand and alocation of the selected charging station, and determining a desiredtime for the specific vehicle to return to service based on thepredicted demand and a location of the selected charging station, and tocompare the desired time to the estimated charging completion time. Insome embodiments, process 1100 may include reassigning at least one userscheduled to be picked up by the specific electric vehicle to adifferent ridesharing vehicle when the estimated charging completiontime is after the desired time to shorten the estimated chargingcompletion time. Process 1100 may also include one or more of making anintermediate stop at the specific charging station while at least onepassenger remains in the specific electric vehicle, and to direct the atleast one passenger to transfer to another ridesharing vehicle at thecharging station, and informing a driver of the another ridesharingvehicle about the at least one passenger before the specific electricvehicle arrives to the charging station.

Managing a Fleet of Petrol and Non-Petrol Ridesharing Vehicles

Embodiments of the present disclosure may allow for a vehicle managementsystem to manage a fleet of vehicles for hire. The fleet of vehicles maycomprise one or more electrically-powered vehicles and one or morepetrol-powered vehicles. An electrically-powered vehicle may be avehicle driven by one or more electric motors using the energy stored inone or more batteries mounted thereon. Exemplary electrically-poweredvehicles include all-electric vehicles, plug-in hybrid electricvehicles, and hybrid vehicles. A petrol-powered vehicle may be a vehicleincluding an internal combustion engine powered by fuel such asgasoline, diesel, or natural gas.

The vehicle management system may receive a plurality of requests for aride from a plurality of users and assign a specific user to a specificvehicle selected from the fleet of vehicles based on the informationrelating to the ride request, current battery-charge data, and/orvehicle location. For example, the vehicle management system maydetermine that the specific vehicle is in need of charging based on thecurrent battery-charge data thereof. The vehicle management system mayalso determine a drop-off location for the user according to theinformation relating to the ride request (e.g., a desired destination),and the drop-off location may be close to the desired destination and acharging station. The vehicle management system may further assign theuser to the specific vehicle and direct the specific vehicle to pick upthe user at a pick-up location and drive to the drop-off location. Thespecific vehicle may drive to the charging station to charge the batteryafter driving the user to the drop-off location.

In some embodiments, the vehicle management system may receive aplurality of requests for ride from a plurality of users, and assign afirst request to a first electrically-powered vehicle and a secondrequest to a second petrol-powered vehicle based on the desireddestinations of the first and second requests, current battery-chargedata of the vehicles, and current vehicle of the vehicles. In someembodiments, the vehicle management system may also provide routes tothe first electrically-powered vehicle and the second petrol-poweredvehicle according to the current battery-charge data.

FIG. 12 depicts an embodiment of memory module 250 for managing a fleetof ridesharing vehicles including electrically-powered ridesharingvehicles consistent with the present disclosure. Memory 250 may store aplurality of modules and may be executable by at least one processor toperform various methods and processes disclosed herein. Further, itshould be noted that memory 250 may store more or fewer modules thanthose shown in FIG. 12, depending on implementation-specificconsiderations.

As illustrated in FIG. 12, memory 250 may store software instructions toexecute a communication module 1201, a ride request module 1202, abattery-charge module 1203, a location module 1204, a database accessmodule 1205, and may include a database 1206. Communication module 1201may include software instruction for communicating with other componentsof ridesharing management system 100 (e.g., one or more user devices120A-120C, driver devices 120D and 120E, driving-control device 120F).Ride request module 1202 may include software instruction for receivingride requests from a plurality of users. Battery-charge module 1203 mayinclude software instruction for receiving battery-charge levels ofridesharing vehicles from one or more sources. Location module 1204 mayinclude software instruction for receiving locations of ridesharingvehicles from one or more sources. Database access module 1205 mayinclude software instruction executable to interact with database 1206,to store and/or receive information (e.g., geographical maps associatedwith a geographical area in which a vehicle is operating, currenttraffic information of a geographical area, historical data forefficient routes, battery-charge data of one or moreelectrically-powered vehicles).

Communication module 1201 may include software instructions forfacilitating communications between the device on which it isimplemented (e.g., ridesharing management server 150) and anothercomponent of ridesharing management system 100 (e.g., mobilecommunications devices 120A-120F, one or more vehicles, database 170).For example, ridesharing management server 150 may receive a pluralityof requests for a ride from a plurality of users (via, e.g., mobilecommunications devices associated with the users) via communicationmodule 1201. As another example, ridesharing management server 150 mayelectronically assign a specific user to a specific vehicle viacommunication module 1201.

Ride request module 1202 may include software instructions for receivinga plurality of requests for a ride from a plurality of users. Each riderequest may include a starting point and a desired destination withinthe geographic area. In some embodiments, ride request module 1202 maydetermine a pick-up location and a drop-off location, the determinedpick-up location being at a location other than but in proximity to thestarting point and the determined drop-off location being at a locationother than but in proximity to the desired destination. Additionally oralternatively, ride request module 1202 may determine the drop-offlocation for a user based on a location of the charging station and thedesired destination of the ride request. For example, in one embodiment,a ride request may include information that the desired destination is abuilding at the corner of an intersection of two cross streets. Riderequest module 1202 may determine that dropping the user off at theintersection would result in the vehicle entering a one-way street,impeding a more efficient route to a charging station. Thus, riderequest module 1202 may instead, for example, drop the user off at alocation proximal to the desired destination, and avoid entering theone-way street. Ride request module 1202 may also electronically assignride requests to one or more vehicles.

Battery-charge module 1203 may include software instructions forreceiving current battery-charge data for an electrically-poweredridesharing vehicle. The data may be related to the remaining charge ofthe battery powering the vehicle and/or an estimated time untildepletion of the battery as captured by a power sensor in the vehiclefor determining the current charge level of the battery. The powersensor may transmit the data to a remote server over a wireless channelor to vehicle routing module to select a charging station, based on thecurrent battery charge level. The power sensor may be configured tocontinuously monitor and transmit data related to the current batterycharge level. The power sensor may also monitor the current batterycharge level and transmit data when the charge level is less than apredetermined threshold level.

In some embodiments, the current battery-charge data may be indicativeof a driving duration and/or distance in which each electrically-poweredridesharing vehicle can operate before charging. Similar tobattery-charge module 1203, battery-charge module 1203 may determine thedriving duration and/or distance based on the current charge level ofthe battery and one or more known characteristics of the vehicle.Alternatively, the vehicle may perform the conversion and send thedriving duration and/or distance to battery-charge module 1203. In someembodiments, the driving duration and/or distance in which theelectrically-powered ridesharing vehicle can operate before rechargingmay correspond to at least one of a driving time and a driving distance.

Additionally or alternatively, battery-charge module 1203 (or thevehicle) may estimate the driving duration using real-time traffic dataalong a current route of the vehicle, using terrain data, such aselevation changes, along a current route of the vehicle, usingdriver-performances data indicative of driver acceleration anddeceleration rates, or the like.

Location module 1204 may include software instructions for receivingcurrent vehicle location data for an electrically-powered ridesharingvehicle. In some embodiments, the current vehicle location data mayinclude global positioning system (GPS) data generated by at least oneGPS component associated with the electrically-powered ridesharingvehicle. Additionally or alternatively, location module 1204 may receiveother location information, such as cell tower triangulation data, Wi-Fior other signal strength data, or any other combination of locationinformation. In one example, location module 1204 may receive thelocation data, for example, from a mobile communication device (e.g., asmartphone, tablet, wearable device, etc.) associated (e.g., located inthe passenger cabin) with the electrically-powered ridesharing vehicle.

Database access module 1205 may include software instructions forinteracting with database 1206, to store and/or receive information.Database 1206 may be configured to store any type of informationassociated with modules 1201-1205, depending on implementation-specificconsiderations.

Modules 1201-1205 may be implemented in software, hardware, firmware, orany combination of software, hardware or firmware. For example, if themodules are implemented in software, they may be stored in memory 250.However, in some embodiments, any one or more of modules 1201-1205 anddata associated with database 1206 may, for example, be stored inprocessor 204 and/or executed on a device associated with ridesharingmanagement system 100. Modules 1201-1205 may be configured to interactwith each other and/or other modules of memory 250 to perform functionsconsistent with disclosed embodiments.

FIG. 13 is a schematic illustration of an exemplary process forassigning a first user to a first vehicle and a second user to a secondvehicle based on the ride requests, battery-charge data, and vehiclelocation data. As illustrated in FIG. 13, a first user 1311 transmits afirst request for a ride to ridesharing management server 150 via afirst user device 120 (not shown). The first request includes a firstpick-up location 1321 and a first desired destination 1331. A seconduser 1312 transmits a second request for a ride to ridesharingmanagement server 150 via a second user device 120 (not shown). Thesecond request includes a second pick-up location 1322 and a seconddesired destination 1332. There are two vehicles, a first vehicle 1341and a second vehicle 1342, that may be available to be assigned to aride request. First vehicle 1341 may be an electrically-powered vehicle,and second vehicle 1342 may be a petrol-powered vehicle. Intuitively, aconventional system may assign first user 1311 to second vehicle 1342and second user 1312 to first vehicle 1341 because second vehicle 1342is closer to the pick-up location of first user 1311 than first vehicle1341 and first vehicle 1341 is closer to the pick-up location of seconduser 1312 than second vehicle 1342. However, the assignment of firstvehicle 1341 to second user 1312 may create problems for first vehicle1341 (an electrically-powered vehicle) if first vehicle 1341 is in needfor charging because there are no any charging locations close todesired destination 1332 of second user 1312. The battery of firstvehicle 1341 may become depleted after first vehicle 1341 drives todesired destination 1332 and before finding a charging station to chargethe battery. As explained below in connection with FIG. 14, additionalvariables may be considered in assigning the ride requests to thevehicles, such as current battery-charge data, desired destinations ofthe requests (or the drop-off locations), locations of the vehicles, orthe like, or a combination thereof.

FIG. 14 is a flowchart showing an exemplary process 1400 for managing afleet of petrol and non-petrol ridesharing vehicles, in accordance withsome embodiments of the present disclosure. In one embodiment, the stepsof process 1400 may be performed by a vehicle management server, such asridesharing management server 150 described above with reference toFIGS. 1 and 3. Alternatively, at least some of the steps of process 1400may be performed by a mobile communications device, such as the mobilecommunications devices 120 described above with reference to FIGS. 1 and2. In the following description, reference is made to certain componentsof FIGS. 1-3 for purposes of illustration. It will be appreciated,however, that other implementations are possible and that othercomponents may be utilized to implement example methods disclosedherein.

At step 1401, ride request module 1202 may receive, via a communicationsinterface, a first request for a ride from a first user. Thecommunications interface may be communications interface 360,communication module 1201, or the like, or a combination thereof. Forexample, a first user may generate a first request for a ride via a userdevice 120 associated with the first user (e.g., an applicationinstalled in user device 120). User device 120 may transmit the firstrequest to ridesharing management server 150, which may receive thefirst request via communication module 1201.

A request (e.g., the first request for a ride or a second request for aride discussed below) may include information related to a pick-uplocation of a user (e.g., the first pick-up location of the first useror the second pick-up location of the second user discussed below). Thepick-up location of the user (or the user device 120 associated with theuser) may be determined according to a current location of the user. Forexample, user device 120 may determine its current location according toGPS signals a GPS component of user device 120 receives. User device 120may also determine the pick-up location according to the currentlocation. For example, user device 120 may designate the currentlocation as the pick-up. Alternatively, user device 120 may determine alocation that is close to the current location and is suitable for theuser to wait for a vehicle (e.g., within a walking distance, avoidingbusy streets, avoiding non-stopping regions) as the pick-up location.Alternatively, user device 120 may recommend a plurality of candidatepick-up locations for the user to choose. For example, user device 120may display a user interface showing a map in which a plurality ofcandidate pick-up locations are shown along with the current location ofthe user. The user may select one of the candidate pick-up locations asthe pick-up location via the user interface. User device 120 may includethe information relating to the pick-up location into the request to betransmitted to ridesharing management server 150.

The ride request may also include a desired destination of the user. Thedesired destination may be determined by user device 120 according tothe user's input. For example, the user may enter the desireddestination in a user interface of user device 120. Alternatively oradditionally, the user may choose the desired destination from a list ofhistorical destination in the user interface. Alternatively oradditionally, the user may enter a partial entry, and user device 120may recommend one or more candidate destinations to the user based onthe requests that the user made in the past. The user may then selectone of the candidate destination(s) as the desired destination.

At step 1403, ride request module 1202 may receive, via thecommunications interface, a second request for a ride from a seconduser. Ride request module 1202 may receive the second request in amanner similar to step 1403 described above. The second request mayinclude information similar to the first request described above and maybe generated based or the same as or similar to the process ofgenerating the first request as described above.

By way of example, as illustrated in FIG. 13, a first user 1311transmits a first request for a ride to ridesharing management server150 via a first user device 120 (not shown). The first request includesa first pick-up location 1321 and a first desired destination 1331. Asecond user 1312 transmits a second request for a ride to ridesharingmanagement server 150 via a second user device 120 (not shown). Thesecond request includes a second pick-up location 1322 and a seconddesired destination 1332. There are two vehicles, a first vehicle 1341and a second vehicle 1342, that may be available to be assigned to aride request. First vehicle 1341 may be an electrically-powered vehicle,and second vehicle 1342 may be a petrol-powered vehicle.

At step 1405, battery-charge module 1203 may receive currentbattery-charge data for the electrically-powered vehicles via, forexample, the communications interface. For example, battery-chargemodule 1203 may periodically receive from an electrically-poweredvehicle the current battery-charge data thereof.

In some embodiments, the current battery-charge data of anelectrically-powered vehicle may include an indication of a drivingduration in which the electrically-powered vehicle can operate withoutcharging. Alternatively or additionally, the battery-charge data mayinclude a mileage to depletion, and the mileage to depletion mayindicate an estimation of how much longer distance the ridesharingvehicle may operate before the battery requires recharging. As anotherexample, battery-charge module 1203 may determine the driving durationand/or distance based on the current charge level of the battery and oneor more known characteristics of the vehicle. In such an example,battery-charge module 1203 may convert the charge level (e.g., measuredin volts or amperes) to a duration and/or distance using a conversionfactor associated with the year, make, and module of the vehicle and/orusing a conversion factor determined from historical data associatedwith the vehicle. Alternatively, the vehicle may perform the conversionand send the driving duration and/or distance to battery-charge module1203.

In some embodiments, the battery-charge data may also includeinformation relating to the charging capacity of an electrically-poweredvehicle. The information relating to the charging capacity of theelectrically-powered vehicle may include the charging capacity of thevehicle battery, the type of the vehicle battery, an indication if thefirst electrically-powered vehicle is a fully electric vehicle or ahybrid vehicle, and/or specific data about the battery performances.Battery-charge module 1203 may save the battery-charge data intodatabase 1206.

In some embodiments, an electrically-powered vehicle may include a powersensor configured to capture its current battery-charge data. Forexample, the power sensor may be configured to continuously monitor andtransmit data related to the current battery charge level. The powersensor may also monitor the current battery charge level and transmitdata when the charge level is less than a predetermined threshold level.

In some embodiments, an electrically-powered vehicle may transmit itscurrent battery-charge data to ridesharing management server 150periodically (e.g., every 5 seconds, every 1 minute, every 5 minutes,every 10 minutes, every 30 minutes, etc.), and ridesharing managementserver 150 may periodically receive the current battery-charge dataaccordingly. Alternatively or additionally, the electrically-poweredvehicle may transmit the current battery-charge data to ridesharingmanagement server 150 according to the battery charge. For example, theelectrically-powered vehicle may transmit the current battery-chargedata to ridesharing management server 150 if the electrically-poweredvehicle determines that the battery charge is less than or equal to athreshold level (e.g., 30% of the full charge), and ridesharingmanagement server 150 may automatically receive the currentbattery-charge data from the vehicle when the battery charge is equal toor below the predefined threshold. In some embodiments, theelectrically-powered vehicle may transmit its current battery-chargedata at different frequencies according to the battery level. Forexample, the electrically-powered vehicle may transmit its currentbattery-charge data to ridesharing management server 150 at a firstfrequency (e.g., every 30 minutes) if the electrically-powered vehicledetermines that the battery level is greater than or equal to 50% of thefull charge, and may transmit its current battery-charge data at asecond frequency (e.g., every 10 minutes) if the electrically-poweredvehicle determines that the battery level is less than 50% of the fullcharge.

In some embodiments, battery-charge module 1203 may receive currentbattery-charge data for the electrically-powered vehicles including atleast one fully electric vehicle and at least one hybrid vehicle.

By way of example, first vehicle 1341 illustrated in FIG. 13, which maybe an electrically-powered vehicle, may transmit its currentbattery-charge data to ridesharing management server 150 periodically orwhen the battery level is less than a threshold.

At step 1407, location module 1204 may receive current vehicle locationdata for the fleet of vehicles. The fleet of vehicles may include aplurality of petrol-powered vehicles and a plurality ofelectrically-powered vehicles. The electrically-powered vehicles mayinclude one or more electrically-powered vehicles that transmit thecurrent battery-charge data to ridesharing management server 150 asdescribed above in connection of step 1405.

The current vehicle location data may include global positioning system(GPS) data generated by at least one GPS component associated with eachvehicle. Additionally or alternatively, location module 1204 may receiveother location information, such as cell tower triangulation data, Wi-Fior other signal strength data, or any other combination of locationinformation. In one example, location module 910 may receive thelocation data, for example, from a mobile communication device (e.g., asmartphone, tablet, wearable device, etc.) associated (e.g., located inthe passenger cabin) with a vehicle.

In some embodiments, a vehicle may transmit its current location data toridesharing management server 150 periodically (e.g., every 30 minutes,every 10 minutes, every 5 minutes, every 1 minute, every 5 seconds) orin real time.

By way of example, location module 1204 may receive current vehiclelocation data of first vehicle 1341 and second vehicle 1342 periodicallyor in real time.

At step 1409, ride request module 1202 may electronically assign thefirst user to a first electrically-powered vehicle and the second userto a second petrol-powered vehicle based on the first and second desireddestinations, the current battery-charge data, and/or the currentvehicle location data. By way of example, ride request module 1202 mayelectronically assign first user 1311 to first vehicle 1341 (which maybe an electrically-powered vehicle) and second user 1312 to secondvehicle 1342 (which may be a petrol-powered vehicle) based on firstdesired destination 1331 and second desired destination 1332, thecurrent battery-charge data, and the current vehicle location data.

In some embodiments, ride request module 1202 may electronically assignthe first user to a first vehicle and the second user to a secondvehicle based on the information relating to the first and secondrequests, the current battery-charge data of one or moreelectrically-powered vehicles, and the current vehicle location data ofone or more vehicles (electrically-powered vehicle and/or petrol-poweredvehicle). The first vehicle may be an electrically-powered vehicle orpetrol-powered vehicle. The second vehicle may be anelectrically-powered vehicle or petrol-powered vehicle. The informationrelating to the first and second requests based on which ride requestmodule 1202 electronically distributes the first and second requests mayinclude the first desired destination, the first pick-up location, thesecond desired destination, or the second pick-up location, or the like,or a combination thereof.

In some embodiments, ride request module 1202 may electronically assignvehicles to the first and second requests according to the currentbattery-charge data of one or more electrically-powered vehicles. Forexample, battery-charge module 1203 may determine whether a firstelectrically-powered vehicle is need of a charge based on the currentbattery-charge data thereof. By way of example, battery-charge module1203 may determine an electrically-powered vehicle is need of charge ifbattery-charge module 1203 determines that the duration in which thefirst electrically-powered vehicle can operate without charging is undera threshold period (e.g., 0.5, 1, 1.5 hours, etc.). Alternatively oradditionally, battery-charge module 1203 may determine theelectrically-powered vehicle is need of charger if battery-charge module1203 determines that the driving distance in which the firstelectrically-powered vehicle can operate without charging is under athreshold distance (e.g., 1 km, 2 km, 5 km, 10 km, 20 km, 50 km, 100 km,200 km, etc.). If ride request module 1202 determines that the firstelectrically-powered vehicle is in need of a charge, ride request module1202 may electronically assign the first user (e.g., first user 1311) tothe first electrically-powered vehicle (e.g., first vehicle 1341) andthe second user (e.g., second user 1312) to a second petrol-poweredvehicle (e.g., second vehicle 1342) despite that first user 1311 may beat a first location (e.g., first pick-up location 1321) closer to secondvehicle 1342 than first vehicle 1341, and that second user 1312 is at asecond location (e.g., second pick-up location 1322) closer to firstvehicle 1341 than second vehicle 1342.

In some embodiments, ride request module 1202 may electronically assignvehicles to the first and second requests further based on one or morecharging locations. A charging location may include a charging stationand/or a charging lane. For example, ride request module 1202 may accessinformation relating to the charging locations stored in database 1206via database access module 1205. Ride request module 1202 may obtain theinformation relating to the charge location (s) in proximity to thedesired destination(s) of the first request and/or the second request.Ride request module 1202 may also determine that a charging location isin proximity to a desired destination if ride request module 1202determines that the charging location is within a radius (e.g., 1 km, 2km, 5 km, 10 km, etc.) to the desired destination (or the desireddestination is within a radius of the charging location). On the otherhand, if ride request module 1202 determines that no charging locationis within the radius to the desired destination, ride request module1202 may determine that no charging location is in proximity to thedesired destination. If ride request module 1202 determines that anelectrically-powered vehicle (e.g., first vehicle 1341) is in need ofcharging and a desired destination of a user (first user 1311) is inproximity to a charging location (e.g., charging station 1351), riderequest module 1202 may electronically assign first vehicle 1341 tofirst user 1311 when the desired destination is in proximity to acharging location. Alternatively or additionally, ride request module1202 may electronically assign second user 1312 to second petrol-poweredvehicle 1342 when the desired destination of second user 1312 is not inproximity to any charging location (e.g., first vehicle 1341 needscharging, and the desired destination of second user 1312 is not with aradius of 10 km of a charging station).

In some embodiments, ride request module 1202 may electronically assignan electrically-powered vehicle to a ride request based on the currentbattery-charge data associated with the electrically-powered vehicle andthe charging capacities of the electrically-powered vehicle. Forexample, ride request module 1202 may access database 1206 to obtain theinformation relating to charging capacities of the electrically-poweredvehicle and receive the current battery-charge data of theelectrically-powered vehicle. The information relating to chargingcapacities of the electrically-powered vehicle may include an indicationif the first electrically-powered vehicle is a fully electric vehicle ora hybrid vehicle, and/or specific data about the battery performances.Ride request module 1202 may assign the electrically-powered vehicle toa ride request based on the information relating to charging capacitiesof the electrically-powered vehicle and the current battery-charge dataof the electrically-powered vehicle.

In some embodiments, ride request module 1202 may determine a drop-offlocation based on information relating to a ride request, and thecurrent battery-charge data, and the location(s) of one or more charginglocations. By way of example, ride request module 1202 may determine adrop-off location that is close to a charging location and a desireddestination of the ride request (e.g., 500 m from the desireddestination and 2 km from the charging location).

In some embodiments, ride request module 1202 may determine a drop-offlocation for each of the first and second requests and respectivelyassign the determined drop-off locations to the first and secondrequests. Ride request module 1202 may electronically assign the firstelectrically-powered vehicle to the first request and the secondpetrol-powered vehicle to the second request based on the drop-offlocations of passengers currently assigned to each of the firstelectrically-powered vehicle and the second petrol-powered vehicle.

At step 1411, ride request module 1202 may transmit instructions todirect the first electrically-powered vehicle to the first pick-uplocation and the second petrol-powered vehicle to the second pick-uplocation via, for example, the communications interface. Ride requestmodule 1202 may also transmit information relating to the first drop-offlocation of the first user (which may be the same as the first desireddestination) to the first electrically-powered vehicle and transmitinformation relating to the second drop-off location of the second user(which may be the same as the second desired destination) to the secondpetrol-powered vehicle. In some embodiments, ride request module 1202may also determine a route from the pick-up location to the drop-offlocation (or the desired destination) for each of the vehicles. Forexample, ride request module 1202 may determine a route for anelectrically-powered vehicle based on the driving duration and/ordistance, real-time traffic data, terrain data (e.g., elevationchanges), driver-performances data indicative of driver acceleration anddeceleration rates, or the like, or a combination thereof. Ride requestmodule 1202 may also direct the first electrically-powered vehicle via afirst determined driving route and to direct the second petrol-poweredvehicle via a second determined driving route. In some embodiments, thefirst driving route may include fewer elevation changes compared to thesecond driving route.

Routing Both Autonomous and Non-Autonomous Vehicles

Embodiments of the present disclosure may allow for a vehicle managementsystem to manage a fleet of vehicles for hire. The fleet of vehicles maycomprise one or more autonomous vehicles-for-hire and one or moremanually-drivable vehicles-for-hire. An autonomous vehicle-for-hire maybe a vehicle-for-hire capable of performing driving tasks without orwith little intervention of a human driver. For example, the autonomousvehicle-for-hire may be a vehicle that has an autonomy level of 4, 5, or6 defined by the Society of Automotive Engineers (SAE) International. Amanually-drivable vehicle-for-hire may be a vehicle that requires ahuman driver's input to perform driving tasks. For example, themanually-drivable vehicle-for-hire may be a vehicle that has an autonomylevel of 0, 1, 2, or 3 defined by the SAE International.

The vehicle management system may receive a request for a ride from aprospective passenger. The system may also electronically assign aspecific vehicle-for-hire that is capable of fulfilling the ride requestto the prospective passenger. The system may further determine thedriving mode of the assigned vehicle (e.g., the assigned vehicle beingin an autonomous vehicle) and determine a route specific to the drivingmode of the assigned vehicle. The system may also wireless transmit thedetermined route to the assigned vehicle.

FIG. 15 is an exemplary embodiment of a memory containing softwaremodules, in accordance with some embodiments of the present disclosure.

Memory 250 may store a plurality of modules and may be executable by atleast one processor to perform various methods and processes disclosedherein. Further, it should be noted that memory 250 may store more orfewer modules than those shown in FIG. 15, depending onimplementation-specific considerations.

As illustrated in FIG. 15, memory 250 may store software instructions toexecute a communication module 1501, a ride request module 1502, a drivemodule 1503, a location module 1504, a route module 1505, a databaseaccess module 1506, and may include a database 1507. Communicationmodule 1501 may include software instruction for communicating withother components of ridesharing management system 100 (e.g., one or moreuser devices 120A-120C, driver devices 120D and 120E, driving-controldevice 120F). Ride request module 1502 may include software instructionfor receiving a request for a ride from a prospective passenger and forelectronically assigning a specific vehicle-for-hire to the prospectivepassenger. Drive module 1503 may include software instruction fordetermining the driving mode of the specific vehicle-for-hire. Locationmodule 1504 may include software instruction for receiving locations ofone or more vehicles from one or more sources. Route module 1505 mayinclude software instruction for determining a specific route for thespecific vehicle-for-hire assigned to the prospective passenger.Database access module 1506 may include software instruction executableto interact with database 1507, to store and/or receive information(e.g., geographical maps associated with a geographical area in which avehicle is operating, current traffic information of a geographicalarea, historical data for efficient routes, battery-charge data of oneor more electrically-powered vehicles).

Communication module 1501 may include software instructions forfacilitating communications between the device on which it isimplemented (e.g., ridesharing management server 150) and anothercomponent of ridesharing management system 100 (e.g., mobilecommunications devices 120A-120F, one or more vehicles, database 170).For example, ridesharing management server 150 may receive a request fora ride from one or more prospective passengers (via, for example, amobile communications device associated with the prospectivepassenger(s)) via communication module 1501. As another example,ridesharing management server 150 may electronically assign a specificvehicle-for-hire to a prospective passenger via communication module1501.

Ride request module 1502 may include software instructions for receivinga request for a ride from one or more prospective passengers. Each riderequest may include a starting point and a desired destination withinthe geographic area. In some embodiments, ride request module 1502 maydetermine a pick-up location and a drop-off location, the determinedpick-up location being at a location other than but in proximity to thestarting point and the determined drop-off location being at a locationother than but in proximity to the desired destination. Additionally oralternatively, ride request module 1502 may determine the drop-offlocation for a prospective passenger based on a location of the chargingstation and the desired destination of the ride request. For example, inone embodiment, a ride request may include information that the desireddestination is a building at the corner of an intersection of two crossstreets. Ride request module 1502 may determine that dropping theprospective passenger off at the intersection would result in thevehicle entering a one-way street, impeding a more efficient route to acharging station. Thus, ride request module 1502 may instead, forexample, drop the prospective passenger off at a location proximal tothe desired destination, and avoid entering the one-way street. Riderequest module 1502 may also electronically assign a specificvehicle-for-hire to the prospective passenger.

Drive module 1503 may include software instructions for determining thedriving mode of a vehicle. For example, drive module 1503 may accessstored information and determine the driving mode of a specificvehicle-for-hire. Database 1507 may store information relating to thedriving modes of a plurality of vehicles. The driving mode may beautonomous or manually drivable. In some embodiments, the driving modemay be autonomous capable (i.e., the vehicle can be autonomously ormanually drivable depending on a selection by the driver or ridesharingmanagement server 150). Drive module 1503 may access and obtain theinformation relating to a specific vehicle-for-hire stored in database1507 via, for example, database access module 1506. Drive module 1503may also determine the drive mode of the vehicle based on the obtainedinformation.

Location module 1504 may include software instructions for receivingcurrent location data for a plurality of vehicles-for-hire and/or aprospective passenger (via, for example, user device 120 associated withthe prospective passenger). In some embodiments, the current locationdata of a vehicle or a prospective passenger may include globalpositioning system (GPS) data generated by at least one GPS componentassociated with the vehicle or prospective passenger. Additionally oralternatively, location module 1504 may receive other locationinformation, such as cell tower triangulation data, Wi-Fi or othersignal strength data, or any other combination of location information.In one example, location module 1504 may receive the location data, forexample, from a mobile communication device (e.g., a smartphone, tablet,wearable device, etc.) associated (e.g., located in the passenger cabin)with the vehicle or prospective passenger.

Route module 1505 may include software instructions for determining amode-specific route for the specific vehicle-for-hire based on thedriving mode of the specific vehicle-for-hire.

Database access module 1506 may include software instructions forinteracting with database 1507, to store and/or receive information.Database 1507 may be configured to store any type of informationassociated with modules 1501-1505, depending on implementation-specificconsiderations.

Modules 1501-1505 may be implemented in software, hardware, firmware, orany combination of software, hardware or firmware. For example, if themodules are implemented in software, they may be stored in memory 250.However, in some embodiments, any one or more of modules 1501-1505 anddata associated with database 1507 may, for example, be stored inprocessor 204 and/or executed on a device associated with ridesharingmanagement system 100. Modules 1501-1505 may be configured to interactwith each other and/or other modules of memory 250 to perform functionsconsistent with disclosed embodiments.

FIG. 16 is a flowchart showing an exemplary process 1600 for managing afleet of ridesharing vehicles, in accordance with some embodiments ofthe present disclosure. The fleet of vehicles include one or moremanually-drivable vehicles-for-hire and one or more autonomousvehicles-for-hire. In some embodiments, the fleet of vehicles includeone or more electrically-powered vehicles and one or more petrol-poweredvehicles. In one embodiment, the steps of process 1600 may be performedby a vehicle management server, such as ridesharing management server150 described above with reference to FIGS. 1 and 3. Alternatively, atleast some of the steps of process 1600 may be performed by a mobilecommunications device, such as the mobile communications devices 120described above with reference to FIGS. 1 and 2. In the followingdescription, reference is made to certain components of FIGS. 1-3 forpurposes of illustration. It will be appreciated, however, that otherimplementations are possible and that other components may be utilizedto implement example methods disclosed herein.

At step 1601, ride request module 1502 may receive a ride request from aprospective passenger via a communications interface. The communicationsinterface may be communications interface 360, or communication module1501, or the like, or a combination thereof. For example, theprospective passenger may generate a request for a ride via a userdevice 120 associated with the prospective passenger (e.g., anapplication installed in user device 120). User device 120 may alsotransmit the ride request to ridesharing management server 150, whichmay receive the ride request via communication module 1501.

The ride request may include information related to a pick-up locationof the prospective passenger. The pick-up location of the prospectivepassenger (or a user device 120 associated with the prospectivepassenger) may be determined according to a current location of theprospective passenger. For example, user device 120 may determine itscurrent location according to GPS signals received by a GPS component ofuser device 120. User device 120 may also determine the pick-up locationaccording to the current location. For example, user device 120 maydesignate the current location as the pick-up location. Alternatively,user device 120 may determine a location that is close to the currentlocation and is suitable for the prospective passenger to wait for avehicle (e.g., within a walking distance, avoiding busy streets,avoiding non-stopping regions) as the pick-up location. Alternatively,user device 120 may recommend a plurality of candidate pick-up locationsfor the prospective passenger to choose. For example, user device 120may display a user interface showing a map in which a plurality ofcandidate pick-up locations are shown along with the current location ofthe prospective passenger. The prospective passenger may select one ofthe candidate pick-up locations as the pick-up location via the userinterface. User device 120 may include the information relating to thepick-up location into the request to be transmitted to ridesharingmanagement server 150.

The ride request may also include information related to a drop-offlocation for the prospective passenger. For example, the prospectivepassenger may enter a desired destination at user device 120. Userdevice 120 may determine a drop-off location based on the entereddesired destination. For instance, user device 120 may simply designatethe desired destination as the drop-off location. Alternatively, userdevice 120 may recommend a drop-off location suitable for theprospective passenger to be dropped off according to the desireddestination (e.g., within walking distance, avoiding busy streets,avoiding non-stopping regions).

In some embodiments, the ride request may also include informationrelated to the preferences of the prospective passenger. For example,user device 120 may ask the prospective passenger regarding his or herpreference regarding whether to avoid riding an autonomous vehicle whenthe prospective passenger initiates a request at user device 120. Theprospective passenger may enter his or her preference at user device120. User device 120 may include such information in the ride request tobe transmitted to ridesharing management server 150. Alternatively oradditionally, user device 120 may receive the preference informationfrom the prospective passenger and store the preference information inthe prospective passenger's profile. When user device 120 generates aride request, user device 120 may automatically include the preferenceinformation in the ride request without the prospective passenger'sinput of preference information. Alternatively or additionally,ridesharing management server 150 may receive such preferenceinformation from user device 120 once and store the preferenceinformation in the prospective passenger's profile (e.g., stored indatabase 1507).

At step 1603, location module 1504 may receive current vehicle locationdata for a plurality of vehicles-for-hire via, for example,communication module 1501. The plurality of vehicles-for-hire mayinclude a plurality of autonomous vehicles-for-hire and a plurality ofmanually-drivable vehicles-for-hire.

In some embodiments, at least one of the plurality of vehicles-for-hireis electrically powered. The electrically-powered vehicle(s) maytransmit battery-charge data to ridesharing management server 150 asdescribed elsewhere in this disclosure. For example, anelectrically-powered vehicle may periodically transmit currentbattery-charge data to ridesharing management server 150. In someembodiments, ridesharing management server 150 may determine whether avehicle-for-hire is an electrically-powered vehicle or a petrol-poweredvehicle by accessing information identifying a powering mode of thevehicle stored in, for example, database 1507.

The current vehicle location data may include global positioning system(GPS) data generated by at least one GPS component associated with eachvehicle. Additionally or alternatively, location module 1504 may receiveother location information, such as cell tower triangulation data, Wi-Fior other signal strength data, or any other combination of locationinformation. In one example, location module 910 may receive thelocation data, for example, from a mobile communication device (e.g., asmartphone, tablet, wearable device, etc.) associated (e.g., located inthe passenger cabin) with a vehicle.

At step 1605, ride request module 1502 may electronically assign aspecific vehicle-for-hire with capacity to fulfill the ride request topick up the prospective passenger based on the current vehicle location.For example, ride request module 1502 may electronically assign avehicle-for-hire that is the closest to the prospective passenger topick up the prospective passenger.

In some embodiments, ride request module 1502 may provide an indicationto the prospective passenger that an autonomous vehicle-for-hire is enroute. For example, ride request module 1502 may transmit a notificationto the prospective passenger (via, for example, user device 120) via thecommunications interface (e.g., communications interface 360,communication module 1501) after electronically assigning an autonomousvehicle-for-hire to the prospective passenger. The notification mayindicate that an autonomous vehicle-for-hire has been assigned to theprospective passenger and is en route. The notification may be in theform of a text message, an audio message, an image, a link, a pushnotification, or an in-app notification, or the like, or a combinationthereof. In some embodiments, ride request module 1502 may also causeuser device 120 associated with the prospective passenger to display auser interface showing a map along with an icon representing the vehicleapproaching the prospective passenger when the vehicle moves toward theprospective passenger. In some embodiments, the notification may alsoinclude a request for the prospective passenger to confirm acceptance ofthe assignment of an autonomous vehicle. The prospective passenger mayaccept or decline the assignment of the autonomous vehicle-for-hireafter receiving the notification, and user device 120 may transmit theconfirmation (acceptance or rejection of the assignment) to ride requestmodule 1502. If a rejection is received from user device 120, riderequest module 1502 may electronically re-assign a manually-drivablevehicle-for-hire to the prospective passenger.

In some embodiments, in assigning a specific vehicle-for-hire to pick upthe prospective passenger, ride request module 1502 may consider variousadditional factors. For example, ride request module 1502 mayelectronically assign a specific vehicle-for-hire to the prospectivepassenger based on the prospective passenger's preference about ridingan autonomous vehicle-for-hire. By way of example, the prospectivepassenger may specify the preference to avoid riding an autonomousvehicle-for-hire in the ride request. Alternatively or additionally,such information may be stored in the prospective passenger's profileaccessible to ride request module 1502. Ride request module 1502 mayprocess the ride request from the prospective passenger to determine ifthe prospective passenger prefers avoiding riding an autonomous vehicle.Ride request module 1502 may also electronically assign amanually-drivable vehicle-for-hire to the prospective passenger despitethat assigning an autonomous vehicle-for-hire would result in a fasterdrop off time for the prospective passenger.

In some embodiments, ride request module 1502 may electronically assigna specific vehicle-for-hire to the prospective passenger based on thepick-up time and/or the drop-off time. For example, ride request module1502 may select at least one manually-drivable vehicle and at least oneautonomous vehicle each capable of fulfilling the ride request. Routemodule 1505 may also calculate a route for each selected vehicle basedon the driving mode of each selected vehicle (i.e., the vehicle beingautonomous or manually-drivable). The route may be from the currentlocation of each vehicle to the pick-up location of the prospectivepassenger. Route module 1505 may further compare each route to currenttraffic data and select the vehicle that has a faster (or the fastest)pick-up time for the prospective passenger as the specificvehicle-for-hire assigned to the prospective passenger. The waitingperiod for the prospective passenger may then be the shortest. In someembodiments, the current traffic data may include information relatingto the restrictions imposed that are specific to autonomous vehicles ormanually-drivable vehicles. Exemplary restrictions may include roadwaysthat are restricted to autonomous vehicles or roadways that arerestricted to manually-drivable vehicles. Exemplary roadways may includeneighborhoods, roads, lanes, or turns, or the like, or a combinationthereof. For example, the current traffic data may include informationrelating to one or more roads that are not open to autonomous vehicles.When determining a route for an autonomous vehicle, route module 1505may exclude such roads from the route planning for the vehicle.

As another example, ride request module 1502 may select at least onemanually-drivable vehicle and at least one autonomous vehicle eachcapable of fulfilling the ride request. Route module 1505 may alsocalculate a route for each selected vehicle from the current location ofthe vehicle to the drop-off location for the prospective passenger(passing the pick-up location) based on the driving mode of the vehicle.Route module 1505 may further compare each route to current traffic dataand select the vehicle that has a faster (or the fastest) drop-off timefor the prospective passenger as the specific vehicle-for-hire assignedto the prospective passenger. The drop-off time may include the time foreach vehicle driving from the current location of each vehicle to thedrop-off location. Alternatively, ride request module 1502 may selectthe vehicle that has a faster (or the fastest) driving time for theprospective passenger as the specific vehicle-for-hire assigned to theprospective passenger. The driving time may be the time for eachselected vehicle from the pick-up location to the drop-off location.

In some embodiments, a vehicle-for-hire may be assigned to two or moreride requests. Ride request module 1502 may electronically assign avehicle-for-hire based on the fastest average drop-off time for theprospective passenger and additional passenger(s) assigned to thevehicle. For example, ride request module 1502 may receive two riderequests, one from the prospective passenger (or referred to as thefirst passenger) and the other from another passenger (or referred to asthe second passenger). Ride request module 1502 may select at least onemanually-drivable vehicle and at least one an autonomous vehicle eachcapable of fulfilling the ride requests for the first passenger and thesecond passenger. Route module 1505 may also calculate a route for eachselected vehicle satisfying the ride requests based on the driving modeof each selected vehicle and the current traffic data. For example,route module 1505 may determine for each selected vehicle a routepassing the current location of the vehicle, and the pick-up locationsand the drop-off locations of the first and second passengers. In someembodiments, the current traffic data may include informationidentifying the restricted road(s) specific to an autonomous vehicle ora manually-drivable vehicle. Ride request module 1502 may alsoelectronically assign the vehicle between (or among) the selectedvehicles that results in a faster (or the fastest) average drop-off timefor the first and second passengers. In some embodiments, the averagedrop-off time may be determined by summing the estimated drop-off timefor the first and second passengers for each of the selected vehiclesand dividing by the total number by two. The estimated drop-off time forthe first and second passengers may change based on the currentpassengers' assignments for each of the selected vehicles.

In some embodiments, ride request module 1502 may electronicallyidentify and assign a specific vehicle-for-hire with capacity to fulfillthe ride request to pick up the prospective passenger based on thenumber of passengers currently (or having been or to be) assigned to thevehicle. For example, ride request module 1502 may electronically assignan autonomous vehicle (whose capacity may be five passengers) to pick upthe prospective passenger if there are four passengers currentlyassigned to the vehicle. As another example, ride request module 1502may electronically assign an autonomous vehicle to pick-up theprospective passenger if the ride request sent by the prospectivepassenger indicates that there are five passengers (including theprospective passenger) on the trip.

At step 1607, drive module 1503 may access stored information anddetermine the driving mode of the specific vehicle-for-hire. Forexample, database 1507 may store information relating to the drivingmode of each of the plurality of vehicles. The driving mode may beautonomous or manually driving. In some embodiments, the driving modemay be autonomous capable (i.e., the vehicle can be autonomously ormanually driving depending on a selection by the driver or ridesharingmanagement server 150). Drive module 1503 may access and obtain theinformation relating to the specific vehicle-for-hire stored in database1507 via, for example, database access module 1506. Drive module 1503may also determine the drive mode of the vehicle based on the obtainedinformation.

At step 1609, route module 1505 may determine (or select) amode-specific route for the specific vehicle-for-hire based on thedriving mode of the specific vehicle-for-hire. The route may include aplurality of links from the current location of the vehicle to thepick-up location and from the pick-up location to the drop-off location.For example, route module 1505 may determine a route for the specificvehicle-for-hire based on current traffic data specific to the drivingmode of the specific vehicle-for-hire. By way of example, route module1505 may determine that the specific vehicle-for-hire is an autonomousvehicle (or a manually-drivable vehicle). Route module 1505 may alsoobtain restrictions specific to autonomous vehicles (ormanually-drivable vehicles) from, for example, database 1507 or athird-party data provider. In some embodiments, database 1507 may storemap data defining roadways that are restricted to autonomous vehicles(and/or manually-drivable vehicles). Route module 1505 may access themap data and determine a route for the specific vehicle-for-hire basedon the restrictions to autonomous vehicles (or manually-drivablevehicles) according to the map data. Exemplary restrictions may includeroadways that are restricted to autonomous vehicles and/ormanually-drivable vehicles. Exemplary roadways may includeneighborhoods, roads, lanes, or turns, or the like, or a combinationthereof. For example, an autonomous vehicle may be restricted fromtaking a right or left turn in a certain area. As another example, amanually-drivable vehicle may be restricted from driving at an expresslane reserved to autonomous vehicles (or vice versa). As a furtherexample, when determining a route for the specific vehicle-for-hire,route module 1505 may exclude restricted roads specific to the specificvehicle-for-hire from the route planning for the vehicle.

In some embodiments, route module 1505 may determine a mode-specificroute for the specific vehicle-for-hire based on the driving mode andthe powering mode of the specific vehicle-for-hire. For example,database 1507 may store the information relating to the powering mode ofthe specific vehicle-for-hire (e.g., being electrically-powered orpetrol-powered). Route module 1505 may access the information relatingto the powering mode and determine the powering mode of the specificvehicle-for-hire. After determining that the specific vehicle-for-hireis an electrically-powered vehicle, route module 1505 may determine (oridentify) at least two mode-specific routes to pick up the prospectivepassenger and select a driving route that includes less elevationchanges and avoids roads restricted to the specific vehicle-for-hire.

At step 1611, ride request module 1502 may wireless transmit informationrelating to the determined (or selected) mode-specific route to thespecific vehicle-for-hire via, for example, network 140. For example,ride request module 1502 may wireless transmit the determined route touser device 120 associated with the specific vehicle-for-hire (or thedriver of the vehicle) or driving-control device 120F if the vehicle isan autonomous vehicle. The route may include a plurality of links fromthe current location of the vehicle to the pick-up location and from thepick-up location to the drop-off location. In some embodiments, riderequest module 1502 may also wireless transmit information relating tothe prospective passenger and/or ride request to the specificvehicle-for-hire. The information transmitted to the vehicle may includethe prospective passenger's name, gender, age, photo, or the like, or acombination thereof.

In some embodiments, ride request module 1502 may receive a pick-upconfirmation from the assigned specific vehicle-for-hire after pickingup the prospective passenger. For example, if the specificvehicle-for-hire is an autonomous vehicle, after picking up theprospective passenger, driving-control device 120F may transmit apick-up confirmation to ride request module 1502. As another example, ifthe specific vehicle-for-hire is a manually-drivable vehicle, the drivermay transmit a pick-up confirmation to ride request module 1502 via userdevice 120 associated with the driver or vehicle. The pick-upconfirmation may include information identifying the prospectivepassenger. Exemplary identification information may include an image,voice, and/or biometric data of the passenger captured at the time ofthe pick-up. Exemplary biometric data may include fingerprint, palmprint, face recognition, iris recognition, retina, or the like, or acombination thereof. For instance, driving-control device 120F (or userdevice 120) may capture a picture of the passenger, which may be used toidentify whether the passenger is the prospective passenger.Alternatively or additionally, ride request module 1502 may receive apick-up confirmation from the prospective passenger after being pickedup by the specific vehicle-for-hire. For example, the prospectivepassenger may transmit a pick-up confirmation via user device 120associated with the prospective passenger to ride request module 1502.In some embodiments, ride request module 1502 may receive a firstpick-up confirmation from the specific vehicle-for-hire and a secondpick-up confirmation from the prospective passenger. More than oneconfirmation may be important in case of the specific vehicle-for-hirebeing an autonomous vehicle. For example, ridesharing management server150 may determine that a particular vehicle has passed the pick-uplocation and ask the prospective passenger via user device 120 toconfirm that the prospective passenger was indeed picked up by thevehicle.

FIG. 17 is a flowchart showing an exemplary process 1700 for selecting aspecific route for a specific vehicle-for-hire, in accordance with someembodiments of the present disclosure. In some embodiments, step 1609 ofprocess 1600 illustrated in FIG. 16 may be performed according toprocess 1700. In some embodiments, the determination of a mode-specificroute for a selected vehicle performed in step 1605 of process 1600illustrated in FIG. 16 when ride request module 1502 determines aspecific vehicle-for-hire to be electronically assigned to a prospectivepassenger may be performed according to process 1700.

At step 1701, route module 1505 may determine a plurality of candidateroutes for a vehicle. The vehicle may be a specific vehicle-for-hireassigned to a prospective passenger or a selected vehicle when riderequest module 1502 determines a specific vehicle-for-hire to beelectronically assigned to a prospective passenger. The candidate routesmay be mode-specific to the driving mode of the vehicle (e.g., beingautonomous or manually-drivable). Each of the candidate routes mayinclude a first segment starting from the current location of thevehicle to the pick-up location for the prospective passenger and/or asecond segment starting from the pick-up location to the drop-offlocation for the prospective passenger.

At step 1703, route module 1505 may determine a pick-up time for each ofthe candidate routes. The pick-up time may be an estimated time for thevehicle driving from its current location to the pick-up location (i.e.,along the first segment of the route).

At step 1705, route module 1505 may determine a drop-off time for eachof the candidate routes. The drop-off time may be an estimated time forthe vehicle driving from its current location to the drop-off location(i.e., along the first and second segments of the route). Alternatively,the drop-off time may be an estimated time for the vehicle driving fromthe pick-up location to the drop-off location (i.e., along the secondsegment of the route).

At step 1707, route module 1505 may select a specific route from theplurality of candidate routes for the vehicle based on at least one ofthe pick-up times and the drop-off times of the candidate routes. Forexample, route module 1505 may select a specific route from thecandidate routes that has a faster (or the fastest) pick-up time. Asanother example, route module 1505 may select a specific route from thecandidate routes that has a faster (or the fastest) drop-off time.

In some embodiments, process 1700 may skip step 1703 after performingstep 1701, where route module 1505 determines a drop-off time for eachof the candidate routes. At 1703, route module 1505 may select aspecific route from the candidate routes that has a faster (or thefastest) drop-off time. Alternatively, after performing steps 1701 and1703, process 1700 may skip step 1705 and proceed to step 1707, whereroute module 1505 selects a specific route from the candidate routesthat has a faster (or the fastest) pick-up time.

Automatically Adjusting Locations Based on Safety Constraints

In some embodiments, a ridesharing vehicle (e.g., autonomous vehicle130F) may receive a ride request from a user, for example, user 130Asent through user device 120A. The ride request may be processed by aridesharing server (such as ridesharing management server 150) andassigned a pick-up location and/or a drop-off location. The ridesharingvehicle may the pick up the user at the assigned pick-up location anddrop off the user at the assigned drop-off location. However, existingsystems do not adjust these locations to ensure safety of the user. Forexample, a pick-up location or drop-off location may be located in anarea experiencing heavy traffic, may lack a sidewalk, may lack a parkinglane or other lane in which the ridesharing vehicle may safely stop, orthe like. This lack in existing systems provides a subpar experience forboth users and drivers. Presently disclosed embodiments, on the otherhand, address this technical problem by automatically adjusting pick-uplocations and/or drop-off locations to improve the experience of usersand drivers. Presently disclosed embodiments use networking technologyand particular hardware sensors to affect the automatic adjustments.

FIG. 18 illustrates an exemplary embodiment of a memory 1800 containingsoftware modules consistent with the present disclosure. In particular,as shown, memory 1800 may include a communications module 1810, avehicle direction module 1820, a traffic data module 1830, a databaseaccess module 1840, and a database 1850. Modules 1810-1840 may containsoftware instructions for execution by at least one processing device,e.g., processor 204, included with a mobile communications device 200associated with a vehicle, or a processor included in the vehicle.Communications module 1810, vehicle direction module 1820, traffic datamodule 1830, database access module 1840, and database 1850 maycooperate to perform multiple operations. For example, communicationsmodule 1810 may receive data identifying a pick-up location of aspecific passenger and data identifying a drop-off location for thespecific passenger from a remote server and may receive, from at leastone sensor traffic data associated with the drop-off location, when anautonomous vehicle-for-hire is in a vicinity of the drop-off location.Vehicle direction module 1820 may electronically direct the autonomousvehicle-for-hire to pick up the specific passenger at the pick-uplocation, electronically direct the autonomous vehicle-for-hire to dropoff the specific passenger at the drop-off location after picking up thespecific passenger, and direct the vehicle-for-hire to the alternativelocation, to drop off the specific passenger at the alternativelocation. Traffic data module 1830 may enable a comparison of thetraffic data obtained from the at least one sensor with safety data todetermine whether dropping off the specific passenger at the drop-offlocation complies with a safety threshold and, when it is determinedthat a drop off at the drop-off location fails to meet the safetythreshold, enable analysis of the traffic data obtained from the atleast one sensor to identify an alternative location, in a vicinity ofthe drop-off location, that complies the safety threshold. Databaseaccess module 1840 may interact with database 1850 which may store anyinformation associated with the functions of modules 1810-1830.

In some embodiments, memory 1800 may be included in, for example, memory250 storing programs including, for example, operating system 252 andcommunication instructions 254, discussed above. Alternatively oradditionally, the components of memory 1810 may be distributed between amobile communications device 200 associated with a vehicle and one ormore ridesharing management servers 150.

In some embodiments, communications module 1810 may receive from theremote server data identifying a pick-up location of a specificpassenger and data identifying a drop-off location for the specificpassenger. A pick-up location may refer to a location at which thespecific passenger is intended to enter a vehicle-for-hire, either asinput by the specific passenger through an input device of an associateduser device (e.g., a mobile communications device 200), determined by alocation service application installed on the user device, or determinedby a remote server (e.g., ridesharing management server 150) in responseto a ride request from the specific passenger. A drop-off location mayrefer to a location where the specific passenger requests to be takento, including for example, a drop off-point located at or near aparticular destination point (e.g., an entrance of a different building)or a location determined by the remote server (e.g., ridesharingmanagement server 150) in response to a ride request from the specificpassenger.

In some embodiments, communications module 1810 may also receive fromthe at least one sensor traffic data associated with the drop-offlocation, when the autonomous vehicle-for-hire is in a vicinity of thedrop-off location. For example, the at least one sensor may include acamera, a radar, a Lidar, or any combination thereof, as discussed belowwith respect to FIG. 19. In such embodiments, communications module 1810may receive the traffic data including image data from the camera and/ordistance data from the radar and/or the Lidar. This traffic data maythen be analyzed, as described below with respect to traffic data module1830.

Additionally or alternatively, the at least one sensor may include amicrophone, a compass, an anemometer, a speedometer, an accelerometer,or the like. In such embodiments, communications module 1810 may receivethe traffic data including measurements from the at least one sensor.This traffic data may then be analyzed, as described below with respectto traffic data module 1830.

Communications module 1810 may additionally or alternatively receivefrom the at least one sensor configured to sense traffic conditions in avicinity of the vehicle-for-hire traffic data associated with thepick-up location. For example, communications module 1810 may receivethe traffic data before picking up the specific passenger at the pick-uplocation.

In any of the embodiments described above, communications module 1810may request and receive information over a computer network tosupplement the traffic data received from the at least one sensor. Forexample, communications module 1810 may receive weather information,traffic information, road maintenance information, or the like from theremote server and/or from one or more additional servers using, forexample, the Internet. This supplemental information may be used in theanalysis performed by traffic data module 1830, as described below.

Communications module 1810 may also transmit data. For example, inembodiments where the pick-up location is adjusted, communicationsmodule 1810 may cause a message including a description of thealternative pick-up location to be transmitted to the specificpassenger. Similarly, in embodiments where the drop-off location isadjusted, communications module 1810 may provide an indication to thespecific passenger about a change in a drop-off location.

Communications module 1810 may transmit the message and/or indicationover one or more computer networks (e.g., the Internet or the like) to auser device (e.g., a mobile communications device 200) associated withthe specific passenger. Alternatively, if the user device is directlypaired with the vehicle-for-hire (e.g., via a wired or wirelessconnection), communications module 1810 may transmit the message and/orindication directly to the user device. Alternatively, communicationsmodule 1810 may transmit the message and/or indication to the remoteserver over one or more computer networks (e.g., the Internet or thelike). The remote server may then relay the message and/or indication tothe user device, e.g., by using one or more computer networks.

The message and/or indication may include coordinates the alternativepick-up or drop-off location (e.g., GPS coordinates, a physical address,or the like), a verbal description of the alternative pick-up ordrop-off location (e.g., 100 meters down the street, next to theStarbucks®, or the like), an image of the alternative pick-up ordrop-off location (e.g., retrieved from local or remote databases ofstreet-level images), or the like. Moreover, the message and/orindication may comprise a push notification, a text message, anindication sent to an app running on the user device for displaying tothe user, or the like.

Vehicle direction module 1820 may electronically direct the autonomousvehicle to pick up the specific passenger at the pick-up location. Forexample, vehicle direction module 1820 may send commands to adriving-control device 120F associated with the vehicle-for-hire.Alternatively, vehicle direction module 1820 may operate using a memoryand/or a processor of driving-control device 120F.

Vehicle direction module 1820 may therefore control one or morecomponents of the vehicle-for-hire. For example, vehicle directionmodule 1820 may control an accelerator, brake, steering mechanism, orthe like of the vehicle-for-hire. Additionally, vehicle direction module1820 may control signaling components such as turn signals, a horn, orthe like of the vehicle-for-hire.

In alternative embodiments, vehicle direction module 1820 may sendcommands to a human driver of the vehicle-for-hire rather thanautonomously controlling the vehicle-for-hire. Accordingly, vehicledirection module 1820 may send directions for display to the driver to adriver device (e.g., driver device 120D-F) associated with thevehicle-for-hire. The directions may be sent using communications module1810.

In embodiments where the pick-up location is adjusted, vehicle directionmodule 1820 may direct the vehicle-for-hire to the alternative pick-uplocation to pick up the specific passenger at the alternative pick-uplocation. Furthermore, vehicle direction module 1820 may, after pickingup the specific passenger, electronically direct the autonomousvehicle-for-hire to drop off the specific passenger at the drop-offlocation. In embodiments where the drop-off location is adjusted,vehicle direction module 1820 may direct the vehicle-for-hire to thealternative location to drop off the specific passenger at thealternative location.

Traffic data module 1830 may enable a comparison of the traffic dataobtained from the at least one sensor with safety data to determinewhether dropping off the specific passenger at the drop-off locationcomplies with a safety threshold. For example, as explained above, theat least one sensor may include a camera, a radar, a Lidar, or anycombination thereof. In such embodiments, traffic data module 1830 mayuse image data from the camera and/or distance data from the radarand/or the Lidar to perform the comparison.

In one example, traffic data module 1830 may use one or moreclassifiers, neural networks, or other object discriminators on theimage data to detect and identify objects such as vehicles (whetherparked or driving behind, in front of, and/or next to thevehicle-for-hire), pedestrians, sidewalks, medians, traffic lights, orthe like. In embodiments where the at least one sensor includes radarand/or Lidar, traffic data module 1830 may first construct a point cloudor other three-dimensional image based on the distance data receivedfrom the radar and/or Lidar and use one or more classifiers, neuralnetworks, or other object discriminators on the point cloud. Althoughthese analyses may be separate, they may be combined. For example,traffic data module 1830 may use one or more classifiers, neuralnetworks, or other object discriminators on a three-dimensionalrepresentation of the vicinity of the vehicle-for-hire derived fromcombining the point cloud with the image data.

In some embodiments, the image data and/or distance data may be derivedfrom a plurality of sensors. For example, a plurality of cameras maycapture a plurality of images that may be assembled together for a moredetailed imaging of the vicinity of the vehicle-for-hire. Additionallyor alternatively, a plurality of radars and/or Lidars may capturedistance measurements over a plurality of fields of view that may beassembled together for a more detailed point cloud of the vicinity ofthe vehicle-for-hire.

In some embodiments, the image data and/or distance data may have beencaptured over time. For example, the image data and/or distance data maycorrespond to the current vicinity of the vehicle-for-hire as well asprevious vicinities, such as those from when the vehicle-for-hire waswithin a threshold distance of the pick-up location and/or the drop-offlocation.

Accordingly, the safety threshold may relate to the detected objects inthe image data and/or the point cloud. For example, the safety thresholdmay take into account at least one of: parked vehicles obstructing thedrop-off or pickup location, traffic obstructions, and road maintenance.Parked vehicles may be detected using the object detection describedabove, as may traffic obstructions (e.g., by detecting other vehicles onthe road and not parked) and indications of road maintenance (e.g., bydetecting construction workers, cones or other barriers, constructionsvehicles such as trucks, cement mixers, or the like, or other objectsindicative of maintenance).

In some embodiments, the safety threshold may be a combination ofweighted parameters determined to ensure that passengers are not pickedup or dropped off at a hazardous location. In such embodiments, theweighted parameters may be associated with at least two of: parkedvehicles obstructing the drop-off location, traffic obstructions, roadmaintenance, weather conditions, and a distance from a sidewalk. Asexplained above, parked vehicle, traffic obstructions, and roadmaintenance may be detected using object detection. Moreover, weatherconditions may be detected using object detection (e.g., by determiningthe slickness of a sidewalk or road based on image data and/orreflectivity data from the radar and/or Lidar or by detecting rain,snow, or the like in the image data) as may sidewalk distances (e.g., bydetecting a sidewalk in the point cloud, by detecting a sidewalk in theimage data and performing triangulation or other distance estimation, orthe like).

Additionally or alternatively, the at least one sensor may include amicrophone, a compass, an anemometer, a speedometer, an accelerometer,or the like, may be used. In such embodiments, traffic data module 1830may use measurements from the at least one sensor to perform thecomparison. For example, traffic data module 1830 may analyze sound datafrom the microphone to determine traffic obstructions (e.g., bydetecting horn honking, lots of vehicle engines, or the like) or roadmaintenance (e.g., by detecting construction noises or the like).Additionally or alternatively, traffic data module 1830 may analyze datafrom the anemometer or other similar sensor to determine weatherconditions. Additionally or alternatively, traffic data module 1830 mayanalyze data from the speedometer, accelerometer, or the like todetermine traffic obstructions (e.g., by detecting frequentaccelerations and decelerations, by detection speeds below a speed limitassociated with a road on which the vehicle-for-hire is traveling, orthe like).

In some embodiments, at least one camera, radar, and/or Lidar may becombined with one or more of a microphone, a compass, an anemometer, aspeedometer, an accelerometer, or the like. For example, detection oftraffic obstructions may depend on a combination of detecting vehiclesin the image data and/or point cloud and detecting traffic noises orpatterns of acceleration and/or speed consistent with trafficobstructions. In another example, detection of road maintenance maydepend on a combination of detecting construction workers, constructionvehicles, or the like in the image data and/or point cloud and detectingnoises consistent with construction activity. In another example,detection of weather conditions may depend on a combination of detectingrain, snow, or the like in the image data and/or point cloud anddetecting meteorological data from an anemometer or other similar sensorconsistent with the detected weather.

Traffic data module 1830 may use information received over a computernetwork to supplement the traffic data received from the at least onesensor. For example, traffic data module 1830 may use weatherinformation, traffic information, road maintenance information, or thelike from the remote server and/or from one or more additional servers.Accordingly, this information may supplement the traffic data from theat least one sensor. For example, the traffic data may be analyzed toconfirm weather, traffic, road maintenance, or the like expected at thedrop-off location based on the information received over the computernetwork.

When it is determined that a drop off at the drop-off location fails tomeet the safety threshold, traffic data module 1830 may enable analysisof the traffic data obtained from the at least one sensor to identify analternative location, in a vicinity of the drop-off location, thatcomplies the safety threshold. For example, as explained above, the atleast one sensor may include a camera, a radar, a Lidar, or anycombination thereof. In such embodiments, traffic data module 1830 mayuse image data from the camera and/or distance data from the radarand/or the Lidar to perform the analysis.

In one example, traffic data module 1830 may use one or moreclassifiers, neural networks, or other object discriminators on theimage data to detect and identify objects such as vehicles (whetherparked or driving behind, in front of, and/or next to thevehicle-for-hire), pedestrians, sidewalks, medians, traffic lights, orthe like. In embodiments where the at least one sensor includes radarand/or Lidar, traffic data module 1830 may first construct a point cloudor other three-dimensional image based on the distance data receivedfrom the radar and/or Lidar and use one or more classifiers, neuralnetworks, or other object discriminators on the point cloud. Althoughthese analyses may be separate, they may be combined. For example,traffic data module 1830 may use one or more classifiers, neuralnetworks, or other object discriminators on a three-dimensionalrepresentation of the vicinity of the vehicle-for-hire derived fromcombining the point cloud with the image data.

As explained above, the object detection may be assessed against thesafety threshold. Accordingly, traffic data module 1830 may identifyalternative locations in the image data and/or distance data and assessthose locations against the safety threshold similarly to the assessmentof the drop-off location described above. Traffic data module 1830 mayrandomly or sequentially assess possible alternative locations or mayuse one or more algorithms to identify optimal alternative locations.For example, traffic data module 1830 may prioritize assessment ofstreet corners, curbside locations near building entrances, or the likeover other possible alternative locations.

Additionally or alternatively, the at least one sensor may include amicrophone, a compass, an anemometer, a speedometer, an accelerometer,or the like. In such embodiments, traffic data module 1830 may usemeasurements from the at least one sensor to perform the analysis. Forexample, traffic data module 1830 may analyze sound data captured by themicrophone near a possible alternative location to determine trafficobstructions (e.g., by detecting horn honking, lots of vehicle engines,or the like) or road maintenance (e.g., by detecting construction noisesor the like). Additionally or alternatively, traffic data module 1830may analyze data from the anemometer or other similar sensor capturednear a possible alternative location to determine weather conditions.Additionally or alternatively, traffic data module 1830 may analyze datacaptured by the speedometer, accelerometer, or the like near a possiblealternative location to determine traffic obstructions (e.g., bydetecting frequent accelerations and decelerations, by detection speedsbelow a speed limit associated with a road on which the vehicle-for-hireis traveling, or the like).

In some embodiments, at least one camera, radar, and/or Lidar may becombined with one or more of a microphone, a compass, an anemometer, aspeedometer, an accelerometer, or the like. For example, detection oftraffic obstructions, road maintenance, weather conditions, or the likemay depend on combinations as explained above.

Traffic data module 1830 may use information received over a computernetwork to supplement the traffic data received from the at least onesensor. For example, traffic data module 1830 may use weatherinformation, traffic information, road maintenance information, or thelike from the remote server and/or from one or more additional servers.Accordingly, this information may supplement the traffic data from theat least one sensor. For example, the traffic data may be analyzed toconfirm weather, traffic, road maintenance, or the like expected atpossible alternative locations based on the information received overthe computer network.

In some embodiments, traffic data module 1830 may identify a pluralityof possible alternative locations and select one as the alternativelocation. The selection may be based, for example, on a ranking of thealternative locations based on the safety threshold. For example, eachpossible alternative location may be assessed and scored (e.g., using ascore out of a maximum, using a percentage score, using a letter grade,or the like) against the safety threshold. The possible alternativelocations may then be ranked and the top scoring one selected.Additionally or alternatively, the ranking may account for the scoringand the distance from the drop-off location such that safety is balancedwith inconvenience. In such an embodiment, a threshold may be applied tothe scorings such that very close alternative locations are not selectedif an associated score is too low.

Additionally or alternatively, traffic data module 1830 may enable acomparison of the traffic data obtained from the at least one sensorwith safety data to determine whether picking up the specific passengerat the pick-up location complies with a safety threshold and determinethat a pick up at the pick-up location fails to meet the safetythreshold. Accordingly, traffic data module 1830 may analyze the trafficdata obtained from the at least one sensor to identify an alternativepick-up location, in a vicinity of the pick-up location, that compliesthe safety threshold. For example, the analyses for the pick-up locationmay be similar to those described above for the drop-off location.

In any of the embodiments described above, the safety threshold may bedynamic rather than static. For example, traffic data module 1830 mayreceive from the remote server (e.g., using communications module 1810)data characterizing the specific passenger and determine a value of thesafety threshold based on the received data. In such an example, if thecharacterizing data indicates that the specific passenger is small child(e.g., below a certain age) or intoxicated, the traffic data module 1830may increase the safety threshold. In embodiments where the safetythreshold is a combination of weighted parameters, the increase may beaffected by adjusting one or more of the weighted parameters, e.g., byreducing a thresholding number of parked vehicles, reducing a thresholdof traffic obstructions, increasing a sensitivity to inclement weathersuch as rain or snow, decreasing a threshold distance to the sidewalk,or the like. Additionally or alternatively, the weights may be adjustedto prioritize particular parameters based on the characterizing data.For example, characterizing data indicating that the specific passengeris intoxicated may result in an adjustment of one or more weightstowards a distance to the sidewalk. In another example, characterizingdata indicating that the specific passenger is below an age thresholdmay result in an adjustment of one or more weights towards trafficobstructions.

Database access module 1840 may cooperate with database 1850 to retrievemap information, traffic data, environmental condition data, and/or anyassociated stored data or metadata. For example, database access module1840 may send a database query to database 1850. Database 1850 mayinclude a map vector-based database or a map raster-based database, anddatabase access module 1840 may be configured to extract a map imagefrom a larger pre-assembled map image, which may be delivered to, forexample, user device 120A-C or driver device 120D-F for display, and/orto driving-control device 120F for use in navigation. In someembodiments, instead of a vector-based or raster-based system, atile-based system may be implemented from database 1950. For example,database access module 1840 may instruct processor 204 to send a requestfor map data to an external map tile server, and mobile devices 120A-Fmay receive a set of map tiles corresponding to a ride request. In otherembodiments, database access module 1840 may instruct a tile makerprogram module to divide raster images into a plurality of discrete maptiles from a painter library or rich map engine library that iscommercially available. Database access module 1840 may instructprocessor 204 to compile a received set of cut map tiles in a grid,position the tile grid with respect to a clipping shape, and may outputthe grid as a single map as part of a user or driver side ridesharingapplication displayed within a GUI or web browser of mobile devices120A-F. Database access module 1840 may select map information inaccordance with GPS data and the pick-up and drop-off locationsspecified by the specific user, a location of the autonomousvehicle-for-hire, and identified locations of traffic obstructions.

Database 1850 may be configured to store any type of information of useto modules 1810-1830, depending on implementation-specificconsiderations. For example, in embodiments in which traffic data module1830 is configured to analyze weather information, traffic information,road maintenance information, or the like, database 1850 may alsoretrieve this information if stored. In another example, in embodimentsin which vehicle direction module 1820 uses map information to directthe autonomous vehicle-for-hire, database 1850 may retrieve thisinformation.

In some embodiments, database 1850 may include separate databases,including, for example, a vector database, raster database, tiledatabase, viewport database, and/or a user input database, configured tostore data. The data stored in database 1850 may be received frommodules 1810-1830, ridesharing management server 150, from user devices120A-F and/or may be provided as input using data entry, data transfer,or data uploading. The data stored in the database 1850 may representmultiple data forms including, for example, general mapping andgeographic information, latitude and longitude (Lat/Lon) values, worldcoordinates, tile coordinates, pixel coordinates, Mercator and/or othermap projection data, user identifier data, driver identifier data,vehicle identifier data, device type data, viewport data, deviceorientation data, user input data, geographical scale data, and avariety of other electronic data. Database 1850 may also include, forexample, street, city, state, and country data including landmarkidentifiers and other related information. Database 1850 may alsoinclude search logs, cookies, web pages, and/or social network content,etc.

Modules 1810-1840 may be implemented in software, hardware, firmware, amix of any of those, or the like. For example, if the modules areimplemented in software, the modules may be stored in a vehicle or in adriver device, such as 120D and 120E, associated with the vehicle.Additionally or alternatively, any one or more of modules 1810-1840 anddata associated with database 1812, may, for example, be stored inprocessor 310 and/or located on ridesharing management server 150, whichmay include one or more processing devices. In some embodiments, aspectsof modules 1810-1840 may include software, hardware, or firmwareinstructions (or a combination thereof) executable by one or moreprocessors, alone or in various combinations with each other. Forexample, modules 1810-1840 may be configured to interact with each otherto perform functions consistent with disclosed embodiments.

FIG. 19 is a block diagram representation of a vehicle 1900 foradjusting pick-up and/or drop-off locations, consistent with theexemplary disclosed embodiments. Vehicle 1900 may include variouscomponents depending on the requirements of a particular implementation.Alternatively, FIG. 19 may represent a driver device, such as 120D and120E, paired to the vehicle. In some embodiments, vehicle 1900 mayinclude one or more processors, such as a data processor 1901 a, animage processor 1901 b, and/or any other suitable processing device; acontrol device 1903; a radar 1905; one or more image acquisitiondevices, such as a camera 1907; a Lidar 1909; one or more memories, suchas memory 1913; and a communications interface 1915 configured tocommunication with remote server 1911.

Similar to processors 204 of mobile communications device 200, both dataprocessor 1901 a and image processor 1901 b may include various types ofhardware-based processing devices. For example, either or both ofapplications processor 1901 a and image processor 1901 b may include amicroprocessor, preprocessors (such as an image preprocessor), graphicsprocessors, a central processing unit (CPU), support circuits, digitalsignal processors, integrated circuits, memory, or any other types ofdevices suitable for running applications and for image processing andanalysis. In some embodiments, applications processor 1901 a and/orimage processor 1901 b may include any type of single or multi-coreprocessor, mobile device microcontroller, central processing unit, etc.Various processing devices may be used, including, for example,processors available from manufacturers such as Intel®, AMD®, etc. andmay include various architectures (e.g., x86 processor, ARM®, etc.).Although FIG. 19 depicts two separate processing devices, more or fewerprocessing devices may be used. For example, in some embodiments, asingle processing device may be used to accomplish the tasks of dataprocessor 1901 a and image processor 1901 b. In other embodiments, thesetasks may be performed by more than two processing devices.

Similar to driving-control device 120F of vehicle 130F, control device1903 may include any type of device suitable for controlling vehicle1900, which may render vehicle 1900 partially or fully autonomous.Control device 1903 may control one or more navigational devices ofvehicle 1900 (not shown), such as a steering component, an accelerator,a brake, or the like.

Radar 1905 may include any type of device suitable for using radio wavesto determine the range, angle, velocity, or the like of target objects.Similarly, Lidar 1909 may include any type of device suitable for usinglight waves to determine the range, angle, velocity, or the like oftarget objects.

Camera 1907 may include any type of device suitable for capturing atleast one image from an environment. Moreover, although depicted in FIG.19 as a single camera, any number of image capture devices may be usedto acquire images for input to the image processor. Some embodiments mayinclude only a single image capture device, while other embodiments mayinclude two, three, or even four or more image capture devices.

Although depicted as including radar 1905, camera 1907, and Lidar 1909,system 1900 may use more or fewer sensing devices. For example, in someembodiments, system 1900 may use camera 1907 paired with Lidar 1909,radar 1905 paired with camera 1907, or the like. In other embodiments,additional sensors such as microphones, a compass, an anemometer, aspeedometer, an accelerometer, or the like, may be used.

Memory 1913 may include software instructions that when executed by aprocessor (e.g., data processor 1901 a and/or image processor 1901 b),may control operation of various aspects of system 1900. These memoryunits may include various databases and image processing software, aswell as a trained system, such as a neural network, or a deep neuralnetwork, for example. In another example, memory 1913 may includeinstructions for performing method 2010 of FIG. 20A and/or method 2050of FIG. 20B, described below. Memory 1913 may include random accessmemory, read only memory, flash memory, disk drives, optical storage,tape storage, removable storage and/or any other types of storage. Insome embodiments, memory 1913 may be a single memory. In otherembodiments, memory 1913 may comprise a plurality of memories. In someembodiments, memory 1913 may be separate from data processor 1901 aand/or image processor 1901 b. In other embodiments, memory 1913 may beintegrated, at least in part, into data processor 1901 a and/or imageprocessor 1901 b.

Remote server 1911 may comprise, for example, ridesharing managementserver 150. Accordingly, remote server 1911 may assign ride requests tovehicle 1900. In some embodiments, remote server 1911 may additionallyreceive sensor data from vehicle 1900 for analysis, as described below.

Similar to communication subsystems 224, communications interface 1915may include one or more devices configured to exchange transmissionsover an air interface to the one or more computer networks (e.g.,cellular, the Internet, etc.) by use of a radio frequency, infraredfrequency, magnetic field, or an electric field. Communicationsinterface 1915 may use any known standard to transmit and/or receivedata (e.g., Wi-Fi, Bluetooth®, Bluetooth Smart, 802.15.4, ZigBee, etc.).Such transmissions may include communications from vehicle 1900 to oneor more remotely located servers, e.g., remote server 1911. As explainedabove, remote server 1911 may transmit ride requests to vehicle 1900using communications interface 1915. Additionally, vehicle 1900 maytransmit data from radar 1905, camera 1907, Lidar 1909, or any othersensors to remote server 1911 for comparison against safety thresholds,and remote server 1911 may, in response, transmit alternative locations(e.g., for pick up or drop off) to vehicle 1900.

FIG. 20A is a flowchart of an example of a method 2010 for dropping offpassengers at a safe location. Steps of method 2100 may be performed bymodules 1810-1840 described above implemented one or more processorsand/or memory 250 of mobile communications device 200 and/or by one ormore processors and/or memory 320 of server 150.

At step 2011, communications module 1810 may receive from a remoteserver (e.g., ridesharing management server 150) data identifying apick-up location of a specific passenger and data identifying a drop-offlocation for the specific passenger. For example, communications module1810 may include software instructions for communicating with the remoteserver configured to electronically receive ride requests fromprospective passengers using a communications interface (e.g., acommunications interface of communication subsystems 224).

At step 2013, vehicle direction module 1820 may electronically direct anautonomous vehicle-for-hire to pick up the specific passenger at thepick-up location. For example, vehicle direction module 1820 may controlone or more components (e.g., an accelerator, a brake, a steeringmechanism, or the like) of the vehicle (e.g., using driving-controldevice 120F).

At step 2015, after picking up the specific passenger, vehicle directionmodule 1820 may electronically direct the autonomous vehicle-for-hire todrop off the specific passenger at the drop-off location. For example,vehicle direction module 1820 may control one or more components (e.g.,an accelerator, a brake, a steering mechanism, or the like) of thevehicle (e.g., using driving-control device 120F).

At step 2017, communications module 1810 may receive from at least onesensor traffic data associated with the drop-off location, when theautonomous vehicle-for-hire is in a vicinity of the drop-off location.For example, as described above with respect to FIG. 19, the at leastone sensor may include at least one of an image sensor, a lidar sensor,a radar sensor.

At step 2019, traffic data module 1830 may enable a comparison of thetraffic data obtained from the at least one sensor with safety data todetermine whether dropping off the specific passenger at the drop-offlocation complies with a safety threshold. For example, as explainedabove with respect to traffic data module 1830, images or other datafrom the at least one sensor may be analyzed to identify objects (suchas sidewalks, parked vehicles, or the like) which are then assessedagainst the safety threshold. In some embodiments, data received usingcommunications module 1810, such as weather updates, road maintenanceupdates, or the like, may be used in combination with the imageanalysis.

In some embodiments, enabling a comparison of the traffic data obtainedfrom the at least one sensor with the safety data to determine whetherdropping off the specific passenger at the drop-off location complieswith the safety threshold may include wireless transmission ofinformation derived from the traffic data to the at least one remoteserver. In such embodiments, enabling a comparison may further includereceiving, in response, information indicative whether the safetythreshold is met.

Additionally or alternatively, enabling a comparison of the traffic dataobtained from the at least one sensor with the safety data to determinewhether dropping off the specific passenger at the drop-off locationcomplies with the safety threshold may include accessing memory, withinthe vehicle-for-hire (e.g., memory 250 of a mobile communications device200 associated with the vehicle-for-hire), containing informationindicative of the safety threshold, and determining, within thevehicle-for-hire, whether the safety threshold is met.

At step 2021, when it is determined that a drop off at the drop-offlocation fails to meet the safety threshold, traffic data module 1830may enable analysis of the traffic data obtained from the at least onesensor to identify an alternative location, in a vicinity of thedrop-off location, that complies the safety threshold. For example,traffic data module 1830 may assess images or other data from the atleast one sensor may be analyzed to identify objects (such as sidewalks,parked vehicles, or the like) which are then scanned to identify one ormore locations satisfying the safety threshold. In some embodiments,data received using communications module 1810, such as weather updates,road maintenance updates, or the like, may be used in combination withthe image analysis to identify the locations.

In some embodiments, traffic data module 1830 may analyze the trafficdata obtained from the at least one sensor to identify an alternativelocation, in a vicinity of the drop-off location, that complies thesafety threshold. For example, traffic data module 1830 may identify aplurality of possible alternative locations and select one as thealternative location. The selection may be based, for example, on aranking of the alternative locations based on the safety threshold.

As explained above, the safety threshold may be a combination ofweighted parameters determined to ensure that passengers are not pickedup or dropped off at a hazardous location. In such embodiments, theweighted parameters may be associated with at least two of: parkedvehicles obstructing the drop-off location, traffic obstructions, roadmaintenance, weather conditions, and a distance from a sidewalk.

Accordingly, the alternative location may be an available curbsidelocation in a vicinity of the drop-off location. Additionally oralternatively, the drop-off location associated with the specificpassenger may also be a pick-up location of a prospective passenger.Accordingly, method 2010 may further include identifying the prospectivepassenger waiting at a location in the vicinity of the drop-offlocation, the waiting location complying with the safety threshold, anddirecting the vehicle-for-hire to the waiting location to drop off thespecific passenger and to pick up the prospective passenger.

At step 2023, vehicle direction module 1820 may direct thevehicle-for-hire to the alternative location, to drop off the specificpassenger at the alternative location. For example, vehicle directionmodule 1820 may control one or more components (e.g., an accelerator, abrake, a steering mechanism, or the like) of the vehicle (e.g., usingdriving-control device 120F).

In some embodiments, method 2010 may further include additional steps.For example, method 2010 may further include receiving from the remoteserver data characterizing the specific passenger and determining avalue of the safety threshold based on the received data. For example,if the characterizing data indicates that the specific passenger iselderly (e.g., above a certain age) or disabled, the traffic data module1830 may increase the safety threshold. In such an example, the increasemay be affected by adjusting one or more of the weighted parameters,e.g., by reducing a thresholding number of parked vehicles, reducing athreshold of traffic obstructions, increasing a sensitivity to inclementweather such as rain or snow, decreasing a threshold distance to thesidewalk, or the like. Additionally or alternatively, the weights may beadjusted to prioritize particular parameters based on the characterizingdata. For example, characterizing data indicating that the specificpassenger is in a wheelchair may result in an adjustment of one or moreweights towards a distance to the sidewalk. In another example,characterizing data indicating that the specific passenger is above anage threshold may result in an adjustment of one or more weights towardstraffic obstructions.

In an additional or alternative example, method 2010 may furtherinclude, before picking up the specific passenger at the pick-uplocation, receiving from the at least one sensor traffic data associatedwith the pick-up location when the vehicle-for-hire is in a vicinity ofthe pick-up location and enabling a comparison of the traffic dataobtained from the at least one sensor with safety data to determinewhether picking up the specific passenger at the pick-up locationcomplies with a safety threshold. In such embodiments, method 2010 mayfurther include determining that a pick up at the pick-up location failsto meet the safety threshold and analyzing the traffic data obtainedfrom the at least one sensor to identify an alternative pick-uplocation, in a vicinity of the pick-up location, that complies thesafety threshold. Additionally, method 2010 may further includedirecting the vehicle-for-hire to the alternative pick-up location, topick up the specific passenger at the alternative pick-up location.Accordingly, method 2010 may include automatically adjusting the pick-uplocation based on a safety threshold in addition to automaticallyadjusting the drop-off location. The safety threshold applied to thepick-up location may be the same threshold or a different threshold thanthat applied to the drop-off location.

In any of the embodiments described above, method 2010 may furtherinclude providing an indication to the specific passenger about a changein a drop-off location. For example, communications module 1810 may sendan alert (e.g., via the remote server using a communications interfaceof communication subsystems 224) to a user device associated with thespecific passenger. For example, the alert may comprise a pushnotification, a text message, an indication sent to an app running onthe user device for displaying to the user, or the like. In embodimentswhere the pick-up location is also adjusted, method 2010 may furtherinclude causing a message including a description of the alternativepick-up location to be transmitted to the specific passenger.

FIG. 20B is a flowchart of an example of another method 2050 for pickingup passengers at a safe location. Steps of method 2000 may be performedby modules 1810-1840 described above implemented one or more processorsand/or memory 250 of mobile communications device 200 and/or by one ormore processors and/or memory 320 of server 150.

In some embodiments, communications module 1810 may communicate with aremote server (e.g., ridesharing management server 150) configured toelectronically receive ride requests from prospective passengers.Accordingly, at step 2051, communications module 1810 may receive fromthe remote server data identifying a pick-up location of a specificpassenger and data identifying a drop-off location for the specificpassenger. For example, communications module 1810 may include softwareinstructions for communicating with the remote server configured toelectronically receive ride requests from prospective passengers using acommunications interface (e.g., a communications interface ofcommunication subsystems 224).

At step 2053, vehicle direction module 1820 may electronically direct anautonomous vehicle to pick up the specific passenger at the pick-uplocation. For example, vehicle direction module 1820 may control one ormore components (e.g., an accelerator, a brake, a steering mechanism, orthe like) of the vehicle (e.g., using driving-control device 120F).

At step 2055, before picking up the specific passenger at the pick-uplocation, communications module 1810 may receive from at least onesensor configured to sense traffic conditions in a vicinity of thevehicle-for-hire traffic data associated with the pick-up location. Forexample, as described above with respect to FIG. 19, the at least onesensor may include at least one of an image sensor, a lidar sensor, aradar sensor.

At step 2057, traffic data module 1830 may enable a comparison of thetraffic data obtained from the at least one sensor with safety data todetermine whether picking up the specific passenger at the pick-uplocation complies with a safety threshold. For example, as explainedabove with respect to traffic data module 1830, images or other datafrom the at least one sensor may be analyzed to identify objects (suchas sidewalks, parked vehicles, or the like) which are then assessedagainst the safety threshold. In some embodiments, data received usingcommunications module 1810, such as weather updates, road maintenanceupdates, or the like, may be used in combination with the imageanalysis.

In some embodiments, enabling a comparison of the traffic data obtainedfrom the at least one sensor with the safety data to determine whetherpicking up the specific passenger at the pick-up location complies withthe safety threshold may include wireless transmission of informationderived from the traffic data to the at least one remote server. In suchembodiments, enabling a comparison may further include receiving, inresponse, information indicative whether the safety threshold is met.

Additionally or alternatively, enabling a comparison of the traffic dataobtained from the at least one sensor with the safety data to determinewhether picking up the specific passenger at the pick-up locationcomplies with the safety threshold may include accessing memory, withinthe vehicle-for-hire (e.g., memory 250 of a mobile communications device200 associated with the vehicle-for-hire), containing informationindicative of the safety threshold, and determining, within thevehicle-for-hire, whether the safety threshold is met.

At step 2059, traffic data module 1830 may determine that a pick up atthe pick-up location fails to meet the safety threshold and analyze thetraffic data obtained from the at least one sensor to identify analternative pick-up location, in a vicinity of the pick-up location,that complies the safety threshold.

In some embodiments, traffic data module 1830 may analyze the trafficdata obtained from the at least one sensor to identify an alternativelocation, in a vicinity of the drop-off location, that complies thesafety threshold. For example, traffic data module 1830 may identify aplurality of possible alternative locations and select one as thealternative location. The selection may be based, for example, on aranking of the alternative locations based on the safety threshold.

As explained above, the safety threshold may be a combination ofweighted parameters determined to ensure that passengers are not pickedup or dropped off at a hazardous location. In such embodiments, theweighted parameters may be associated with at least two of: parkedvehicles obstructing the drop-off location, traffic obstructions, roadmaintenance, weather conditions, and a distance from a sidewalk.

At step 2061, vehicle direction module 1820 may direct thevehicle-for-hire to the alternative pick-up location, to pick up thespecific passenger at the alternative pick-up location. For example,vehicle direction module 1820 may control one or more components (e.g.,an accelerator, a brake, a steering mechanism, or the like) of thevehicle (e.g., using driving-control device 120F).

At step 2063, communications module 1810 may cause a message including adescription of the alternative pick-up location to be transmitted to thespecific passenger. For example, communications module 1810 may send analert (e.g., via the remote server using a communications interface ofcommunication subsystems 224) to a user device associated with thespecific passenger. For example, the alert may comprise a pushnotification, a text message, an indication sent to an app running onthe user device for displaying to the user, or the like.

In some embodiments, method 2050 may further include additional steps.For example, method 2050 may further include receiving from the remoteserver data characterizing the specific passenger and determining avalue of the safety threshold based on the received data. For example,if the characterizing data indicates that the specific passenger iselderly (e.g., above a certain age) or disabled, the traffic data module1830 may increase the safety threshold. In such an example, the increasemay be affected by adjusting one or more of the weighted parameters,e.g., by reducing a thresholding number of parked vehicles, reducing athreshold of traffic obstructions, increasing a sensitivity to inclementweather such as rain or snow, decreasing a threshold distance to thesidewalk, or the like. Additionally or alternatively, the weights may beadjusted to prioritize particular parameters based on the characterizingdata. For example, characterizing data indicating that the specificpassenger is in a wheelchair may result in an adjustment of one or moreweights towards a distance to the sidewalk. In another example,characterizing data indicating that the specific passenger is above anage threshold may result in an adjustment of one or more weights towardstraffic obstructions.

In an additional or alternative example, method 2050 may further includereceiving from the at least one sensor traffic data associated with thedrop-off location, when the autonomous vehicle-for-hire is in a vicinityof the drop-off location, and enabling a comparison of the traffic dataobtained from the at least one sensor with safety data to determinewhether dropping off the specific passenger at the drop-off locationcomplies with a safety threshold. In such embodiments, method 2050 mayfurther include, when it is determined that a drop off at the drop-offlocation fails to meet the safety threshold, enabling analysis of thetraffic data obtained from the at least one sensor to identify analternative location, in a vicinity of the drop-off location, thatcomplies the safety threshold. Additionally, method 2050 may furtherinclude directing the vehicle-for-hire to the alternative location, todrop off the specific passenger at the alternative location.Accordingly, method 2050 may include automatically adjusting thedrop-off location based on a safety threshold in addition toautomatically adjusting the pick-up location. The safety thresholdapplied to the drop-off location may be the same threshold or adifferent threshold than that applied to the pick-up location.

In embodiments where the drop-off location is also adjusted, method 2050may further include providing an indication to the specific passengerabout a change in a drop-off location.

Prescheduling a Rideshare with an Unknown Pick-Up Location

Consistent with the following embodiments, a system (e.g., automatedridesharing dispatch system 300) may be configured to direct ridesharingvehicles to provide transportation services to on-demand users and toprescheduling users. On-demand users are individuals interested in aride in the immediate future, e.g., within one minute, within 5 minutes,within 10 minutes, or within 30 minutes. After receiving a request froman on-demand user, the system is configured to find an availableridesharing vehicle and direct both the ridesharing vehicle and theon-demand user to meet up at a virtual bus stop. Typically, the timeduration from when an on-demand user requests the ride until theon-demand user is picked up by a ridesharing vehicle is less than 45minutes, less than 30 minutes, or less than 15 minutes. In contrast,prescheduling users are individuals interested in a ride in thenon-immediate future, e.g., in the next hour, in the next 2 hours, inthe next 4 hours, in the next 24 hours, or after 24 hours. Afterreceiving a request from a prescheduling user, the system may store therequest for future processing. At a certain time, prior to the requestedpick-up time, the system may find an available ridesharing vehicle anddirect both the ridesharing vehicle and the prescheduling user to meetup at a virtual bus stop. Typically, the time duration from when theprescheduling user requests the ride until the prescheduling user ispicked up by a ridesharing vehicle may be greater than one hour, 2hours, 4 hours, 24 hours, or great than 24 hours. While the generalconcept of prescheduling a ride is known, existing preschedulingservices are inflexible and inefficiently use the resources of theirfleet of vehicles. A classic example for the inefficiently of existingprescheduling services is when a user stays at a hotel and wants toshare a ride to the airport. Existing prescheduling service may offer topick up the user from the hotel, but only at predetermined times thatfit the service's pick-up schedule. In most cases, the vehicle assignedto pick up the user from the hotel is a vehicle dedicated fortransporting hotel guests to the airport, and it cannot toleratereal-time changes (e.g., unexpected passengers). Also, it is very commonfor an almost full vehicle to undertake a substantial detour to pick upa single passenger from a remote hotel, or for a fourteen-seater van totransport a single passenger to the airport. In contrast, as describedin greater detail below, the system may store requests fromprescheduling users and dynamically assign an available ridesharingvehicle considering real-time conditions. Moreover, the system canintegrate prescheduling service with on-demand service to improve fleetmanagement technology and to increase productivity.

FIG. 21 illustrates an exemplary embodiment of a memory 2100 containingsoftware modules consistent with the present disclosure. In particular,as shown, memory 2100 may include a data capture module 2102, a requestsmanagement module 2104, a vehicle-passenger (V-P) assignment module2106, a route determination module 2108, a transmission module 2110, adatabase access module 2112, and a database 2114. Modules 2102, 2104,2106, 2108, 2110, and 2112 may contain software instructions forexecution by at least one processing device, e.g., processor 310,included with the suggested system. Data capture module 2102, requestsmanagement module 2104, V-P assignment module 2106, route determinationmodule 2108, transmission module 2110, database access module 2112, anddatabase 2114 may cooperate to perform multiple operations. For example,data capture module 2102 may receive ride requests from a plurality ofusers (e.g., prescheduling users and on-demand users) and receiveindications of current locations of the plurality of ridesharingvehicles. Requests management module 2104 may store at database 2114requests from the prescheduling users and manage the requests from theprescheduling users and the on-demand users. In one implementation,requests management module 2104 may forward to V-P assignment module2106 a request from a prescheduling user at least 30 minutes before therequested pick-up time. V-P assignment module 2106 may use informationfrom data capture module 2102 and requests management module 2104 toassign a ridesharing vehicle to a plurality of users. For example, V-Passignment module 2106 may select a single ridesharing vehicle fortransporting together prescheduling users and on-demand users based onthe starting points and desired destinations of the prescheduling usersand the on-demand users. Route determination module 2108 may determine aroute for the selected ridesharing vehicle. For example, routedetermination module 2108 may determine a single shared pick-up locationfor one of the prescheduling users and one of the on-demand users.Transmission module 2110 may use a communications interface for sending,to a plurality of users, information about the pick-up location and forsending to the selected ridesharing vehicle driving directions based onthe determined route. Database access module 2112 may interact withdatabase 2114 which may store requests from prescheduling users and anyother information associated with the functions of modules 2102-2112.

In some embodiments, memory 2100 may be included in, for example, memory320. Alternatively or additionally, memory 2100 may be stored in anexternal database 170 (which may also be internal to ridesharingmanagement server 150) or external storage communicatively coupled withridesharing management server 150, such as one or more databases ormemories accessible over network 140. Further, in other embodiments, thecomponents of memory 2100 may be distributed in more than one server.

In some embodiments, data capture module 2102 may receive ride requestsfrom a plurality of prescheduling users and on-demand users; each riderequest may include information indicative of a starting point, adesired destination, and a requested pick-up time. The informationindicative of the starting point may include a current location of theuser, as inputted by each user through an input device of an associateduser device or as determined by a location service application installedon the user device. The information indicative of the desireddestination may refer to a location and/or address where the userdesires to be taken to, for example, an entrance of a shopping center,or a stored location (e.g., home, work, etc.). The informationindicative of the requested pick-up time may include a requested time todepart from the starting point and start walking toward the pick-uplocation, a requested time to be picked up by the ridesharing vehicle,or a requested time to reach the desired destination. In one embodiment,the system may determine when to pick up prescheduling users based onthe requested times to reach their desired destinations. For example,the system may take into account the time to walk to the pick-uplocation from the starting point, predicted traffic conditions, the timeto walk from the drop-off location to the desired destination, and more.For on-demand users the requested pick-up time may be assigned as ASAP(as soon as possible) according to, for example, a default setting. Insome embodiments, data capture module 2102 may also receive from aplurality of communication devices associated with a plurality ofridesharing vehicles indications of current locations of the pluralityof ridesharing vehicles. The current locations of the plurality ofridesharing vehicles may be determined by a location service applicationinstalled on a driver device, a driving-control device, or by a locationdetermination component in the ridesharing management system 100, whichmay be a part of or separate from ridesharing management server 150. Forexample, the indications of current locations of the plurality ofridesharing vehicles may include global positioning system (GPS) datagenerated by at least one GPS component associated with each ridesharingvehicle.

In some embodiments, requests management module 2104 may includeinstructions configured to determine if the ridesharing requestsoriginate from on-demand users or from prescheduling users, determinepreference parameters for each ridesharing request, and timely forwardthe ridesharing requests to V-P assignment module 2106. In someembodiments, requests management module 2104 may include instructionsconfigured to determine user preference parameters for each ridesharingrequest by accessing users' profiles stored in database 2114. Forexample, user preference parameters may include: a maximum walkingdistance from a starting point to a pick-up location, a maximum walkingdistance from a drop-off location to a desired destination, a totalmaximum walking distance involved in a ride, a maximum number ofsubsequent pick-ups, a maximum delay of arrival/detour incurred bysubsequent pick-ups during a ride, and a selection whether to permittoll road usage during the ride, etc. The user preference parameters maybe taken into account when ridesharing management server 150 selects aridesharing vehicle to pick up the users. In some embodiments, requestsmanagement module 2104 may include instructions configured to forwardthe ridesharing requests to V-P assignment module 2106 based on theinformation indicative of the requested pick-up time in the requests.For example, the ridesharing pre-scheduled requests may be forwarded toV-P assignment module 2106 at least 15 minutes before the requested timeto be picked up, at least 20 minutes before the requested time to bepicked up, or at least 30 minutes before the requested time to be pickedup. Additionally, ridesharing requests by on-demand users may beforwarded to V-P assignment module 2106 at a FCFS (first come firstserve) basis.

In some embodiments and as illustrated in FIGS. 22A-22C, V-P assignmentmodule 2106 may assign a single ridesharing vehicle to a plurality ofusers that includes at least two prescheduling users and at least one ofon-demand user. In other words, V-P assignment module 2106 may assign aplurality of users of different types to a common ridesharing vehicle.In one embodiment, V-P assignment module 2106 may avoid assigningadditional on-demand users to a specific ridesharing vehicle carrying aprescheduling user when it is estimated that the assignment may causethe prescheduling user to arrive at the desired destination after therequested time. In another embodiment, V-P assignment module 2106 mayassign users to a ridesharing vehicle based on user preferenceparameters received from requests management module 2104. Ridesharingmanagement server 150 may further be configured to receive user inputfrom user devices (e.g., user devices 120A-120C) as to various rideservice parameters and may assign a ridesharing vehicle to pick up theusers accordingly.

In some embodiments, route determination module 2108 may determine aroute for the selected ridesharing vehicle. The determined route mayinclude a plurality of pick-up and drop-off locations associated withthe starting points and desired destinations of the plurality of users.Consistent with the present disclosure, determining the driving routemay include selecting pick-up locations and drop-off locations for eachof the plurality of users (commonly referred to as “virtual bus stops”),and determining the path between the virtual bus stops. The determinedroute may pass between all the determined pick-up points. When selectinga virtual bus stop, route determination module 2108 may confirm that thepick-up location is within a maximum walking distance (e.g., 300 metersor less) from the starting point, and that the drop-off location iswithin a maximum walking distance (e.g., 300 meters or less) from thedesired destination. The virtual bus stops for the plurality of usersand the driving route may be determined to minimize at least one of: atime duration each user spends in the ridesharing vehicle, a timeduration each user spends waiting at the pick-up location, a distanceeach user needs to walk from the starting point to the pick-up location,a distance each user needs to walk from the drop-off location to thedesired destination, and the number of empty seats in the ridesharingvehicle. When determining the route for the selected ridesharingvehicle, route determination module 2108 may determine a route that willallow the prescheduling user to arrive at the desired destination by therequested time or will allow the prescheduling user to be picked up bythe requested time.

In some embodiments, transmission module 2110 may communicate, based oninstructions from V-P assignment module 2106, with ridesharingmanagement server 150 to send to the selected ridesharing vehicle, viathe communications interface, driving directions according to thedetermined route. As discussed above, communications interface 360 mayinclude a modem, Ethernet card, or any other interface configured toexchange data with a network, such as network 140 in FIG. 1. Forexample, ridesharing management server 150 may include software that,when executed by a processor, provides communications with network 140through communications interface 360 to one or more mobilecommunications devices 120A-F. In some embodiments, transmission module2110 may further send to the user, via the communications interface,information that causes a display of walking directions from thestarting point to the pick-up location and from drop-off location to thedesired destination. Transmission module 2110 may further send viacommunications interface messages to prescheduling users when aridesharing vehicle is assigned to pick them up. The messages may appearin different formats, for example, a text message, an audio message, ora graphical image, which may include text. In one embodiment,transmission module 2110 may receive confirmation from the preschedulingusers before transmitting an updated route to the selected ridesharingvehicle that includes the respective pick-up locations of theprescheduling users.

In some embodiments, database access module 2112 may cooperate withdatabase 2114 to retrieve pending requests of prescheduling users, mapinformation, traffic data, environmental condition data, and/or anyassociated stored data or metadata. For example, database access module2112 may send a database query to database 2114 which may be associatedwith database 170. Database 2114 may be configured to store any type ofinformation of use to modules 2102-2112, depending onimplementation-specific considerations. For example, requests managementmodule 2104 may be configured to store requests of prescheduling usersin database 2114 and forward them to V-P assignment module 2106 apredetermined period of time before the requested time to be picked up.In some embodiments, database 2114 may store indications of locations ofplurality of ridesharing vehicles received from data capture module 2102and information providing a description of the nature, time, and/or dateof any traffic conditions and/or environmental conditions received froma third party entity. Additionally, as discussed above, database 2114may store general information collected from the users (e.g., userpreference parameters).

In some embodiments, database 2114 may include separate databases,including, for example, a vector database, raster database, tiledatabase, viewport database, and/or a user input database, configured tostore data. The data stored in database 2114 may be received frommodules 2102-2112, from ridesharing management server 150, from userdevices 120A-F, and/or may be provided as input using data entry, datatransfer, or data uploading. The data stored in database 2114 mayrepresent multiple data forms including, for example, general mappingand geographic information, latitude and longitude (Lat/Lon) values,world coordinates, tile coordinates, pixel coordinates, Mercator and/orother map projection data, user identifier data, driver identifier data,vehicle identifier data, device type data, viewport data, deviceorientation data, user input data, geographical scale data, and avariety of other electronic data. Database 2114 may also include, forexample, street, city, state, and country data including landmarkidentifiers and other related information. Database 2114 may alsoinclude search logs, cookies, web pages, and/or social network content,etc.

Modules 2102-2112 may be implemented in software, hardware, firmware, amix of any of those, or the like. For example, if the modules areimplemented in software, the modules may be stored in a server (e.g.,ridesharing management server 150) or distributed over a plurality ofservers. In some embodiments, any one or more of modules 2102-2112 anddata associated with database 2114 may, for example, be stored inprocessor 310 and/or located on ridesharing management server 150, whichmay include one or more processing devices. Processing devices ofridesharing management server 150 may be configured to execute theinstructions of modules 2102-2112. In some embodiments, aspects ofmodules 2102-2112 may include software, hardware, or firmwareinstructions (or a combination thereof) executable by one or moreprocessors, alone or in various combinations with each other. Forexample, modules 2102-2112 may be configured to interact with each otherand/or other modules of ridesharing management server 150 to performfunctions consistent with disclosed embodiments.

FIG. 22A is a diagram showing an example timeline 2200 illustrating howridesharing management server 150 may assign two prescheduling users andan on-demand user to a same ridesharing vehicle, according to disclosedembodiments. Timeline 2200 includes three time periods: a first timeperiod, a second time period, and a third time period. Consistent withthe present disclosure, in one embodiment, the second time period may bemore than one hour, two hours, four hours, twenty hours, after the firsttime period, and the third time period may be between the first timeperiod and the second time period. For example, the third time periodmay start more than one hour after the first time period and may end 15minutes before the second time period. Consistent with the presentdisclosure, the first time period, the second time period, and the thirdtime period are time periods that do not overlap and that are smallerthan two hours, smaller than one hour, or smaller than half an hour. Intimeline 2200, the first time period starts at 22:00 and ends at 23:30,the third time period starts at 5:00 and ends at 6:00, and the secondtime period starts at 7:30 and ends at 8:30. The manner and order inwhich events are shown in timeline 2200 is chosen for convenience andclarity of presentation and is not intended to limit the disclosedembodiments. Instead, the proper chronological relationship betweenevents shown in timeline 2200 is defined by the appended claims. Inparticular, the third time period may be a short time interval of only afew minutes.

During the first time period, at step 2202, ridesharing managementserver 150 may receive a shared-ride request from a first preschedulinguser (hereinafter “user P1”). The shared-ride request from user P1 mayinclude a first requested pick-up time during the second time period anda first starting point. For example, at 22:15, user P1 may request to bepicked up at 7:45 from near his/her current location. Also during thefirst time period, at step 2204, ridesharing management server 150 mayreceive a shared-ride request from a second prescheduling user(hereinafter “user P2”). The shared-ride request from user P2 may alsoinclude a second requested pick-up time during the second time periodand second differing starting point. For example, at 22:45, user P2 mayrequest to be picked up at 8:15 from near his/her home (which may bedifferent from his/her current location). Ridesharing management server150 may store the first and second requests for processing during thethird time period.

During the third time period, at step 2206, ridesharing managementserver 150 may receive a third shared-ride request from a firston-demand user (hereinafter “user OD1”). The third shared-ride requestfrom user OD1 may include a third starting point that is close to butdifferent from the first starting point of user P1. Thereafter, at step2208, ridesharing management server 150 may receive current vehiclelocation data for a plurality of ridesharing vehicles. As discussedabove, the current vehicle location data may include global positioningsystem (GPS) data generated by at least one GPS component associatedwith each of the plurality of ridesharing vehicles. Consistent with thepresent disclosure, at step 2210 ridesharing management server 150 mayprocess the first request, the second request, the third request, andthe vehicle location data to identify and assign a specific ridesharingvehicle for transporting users OD1, P1, and P2. Then, at step 2212,ridesharing management server 150 may calculate a ridesharing route forpicking up the assigned users. The ridesharing route may include pick-uplocations for users OD1, P1, and P2 that are different from theirrespective starting points. In this example, since the first startingpoint of user P1 and the third starting point of user OD1 are close toeach other, ridesharing management server 150 may determine a singlepick-up location for users OD1 and P1. The determination of the pick-uplocation for users OD1 and P1 may be based on the first starting pointof user P1 and the third starting point of user OD1. In addition, duringthe third time period, when ridesharing management server 150 isprocessing the first, second, and third shared-ride requests, thespecific ridesharing vehicle may be on route to pick up a secondon-demand user (hereinafter “user OD2”) that also requested the sharedride during the third time period (user OD2 is not shown in timeline2200). In one embodiment, ridesharing management server 150 maydetermine the pick-up location for users OD1 and P1 based on thedetermined drop-off location of user OD2. In another embodiment,ridesharing management server 150 may determine the drop-off location ofuser OD2 based on the pick-up location for users OD1 and P1.

After the third time period and before the second time period, at step2214, ridesharing management server 150 may wirelessly transmit to usersOD1, P1, and P2 their respective pick-up locations. At step 2216,ridesharing management server 150 may wirelessly transmit to thespecific ridesharing vehicle the calculated route for picking up usersOD1, P1, and P2 during the second time period. As depicted in timeline2220, ridesharing management server 150 may wirelessly transmit to usersOD1, P1, and P2 their respective pick-up locations at a time closer tothe second time period than the first time period. In one embodiment,after wirelessly transmitting to users OD1, P1, and P2 the respectivepick-up locations, ridesharing management server 150 is configured towait for receiving confirmation from users P1 and P2 before transmittingthe calculated route to the specific ridesharing vehicle. Ridesharingmanagement server 150 may not wait for receiving confirmation from userOD1 since user OD1 is an on-demand user. Alternatively, Ridesharingmanagement server 150 may receive an immediate confirmation from userOD1.

During the second time period, at step 2218, the specific ridesharingvehicle may pick up users OD1 and P1 from the same pick-up location.After picking up users OD1 and P1, at step 2220, ridesharing managementserver 150 may determine the drop-off location for user OD1. Thedetermination of the drop-off location for user OD1 may be based on thepick-up location of user P2. At step 2222, the specific ridesharingvehicle may drop off user OD1 at the determined drop-off location andcontinue driving to pick up user P2 (step 2224).

After the second time period, at step 2226, ridesharing managementserver 150 may determine the drop-off location of user P2. Similar totimeline 520 illustrated in FIG. 5, ridesharing management server 150may determine a drop-off location for user P2 that is after the pick-uplocation of user P1 and before the drop-off location of user P1. In oneembodiment, ridesharing management server 150 may determine the drop-offlocation of user P2 based on a current location of the specificridesharing vehicle and the requested time of user P2 to reach thedesired destination. For example, when (for any reason) the specificridesharing vehicle is running late, ridesharing management server 150may decide to drop off user P2 closer to the desired destination toprevent user P2 from walking a long distance. At step 2228, the specificridesharing vehicle may drop off user P2 at a location that is differentfrom the desired destination of user P2. Consistent with the presentdisclosure, ridesharing management server 150 may determine a drop-offlocation for user P1 after determining the drop-off location of user P2,and even after dropping off user P2. Specifically, as depicted intimeline 2200, ridesharing management server 150 may determine thedrop-off location of user P1 at step 2230 and the specific ridesharingvehicle may drop off user P1 at step 2232.

FIG. 22B and FIG. 22C are schematic diagrams of examples of mapsillustrating some of the events shown in timeline 2200. Map 2240,illustrated in FIG. 22B, depicts representation of events that tookplace during the first time period. Specifically, map 2240 depicts thefirst starting point of user P1 as indicated in the first shared-riderequest, and the second starting point of user P2 as indicated in thesecond shared-ride request. Around each starting point there is a dashedcircle that represents the individual (or globally defined) maximumwalking distance from a starting point to a pick-up location. Asdescribed above, the system may determine the maximum walking distancebased on user preference parameters derived from the users' profilesstored in database 2114. During the first period of time, neitherridesharing management server 150 nor users P1 and P2 have knowledge ofthe exact location for pick-up location, only an estimation based ontheir starting points specified in the shared-ride request and thedetermined maximum walking distances.

Map 2245, illustrated in FIG. 22C, depicts representations of some ofthe events that took place during the first and second time period.Specifically, map 2245 depicts the third starting point of user OD1 asindicated in the third shared-ride request. Based on the receivedcurrent vehicle location data, the system may identify two ridesharingvehicles (namely, ridesharing vehicle 2250A and ridesharing vehicle2250B) in the area of users OD1 and P1. In one embodiment, ridesharingmanagement server 150 may select the specific ridesharing vehicle basedon the desired destination of passengers currently riding the identifiedridesharing vehicles. For example, if the desired destination of user P1is somewhere downtown and ridesharing vehicle 2250A is heading uptown,ridesharing management server 150 may select ridesharing vehicle 2250B.Map 2245 also depicts the pick-up locations of users OD1, P1, and P2,and the walking paths from the users' starting points to their assignedpick-up locations. In the scenario described in timeline 2200,ridesharing management system 100 had received the third shared-riderequest before determining the pick-up location for user P1, thereforethe pick-up location was determined at a location between the startingpoints of users OD1 and P1. In a similar scenario, if user OD1 hadrequested the ride-share after the pick-up location was transmitted touser P1 (e.g., after 7:00), user OD1 may be directed to a differentpick-up location. In one embodiment, user OD1 may request a ride-shareafter picking up user P1 or even after dropping off user P1.

FIG. 22C also depicts two possible routes (namely, route 2255A and route2255B) for directing the selected ridesharing vehicle. As shown, route2255A passes closer to the second starting point of user P2 than route2255B, but route 2255B passes closer to the desired destination of userOD1. If the system had calculated the ridesharing route for picking upassigned users during the first period of time, route 2255A may havebeen selected. But, since the system calculates the ridesharing routefor picking up assigned users during the third period of time (afterreceiving the third request), the system may select route 2255B. Inother words, the pick-up location of a prescheduling user may bedetermined based on a desired destination of an on-demand user thatrequested the ride hours after the prescheduling user requested theride.

In one embodiment, a system may direct a ridesharing vehicle. The systemmay include a communications interface and at least one processor. Thecommunications interface may be configured to receive requests forshared-rides from a plurality of users. The at least one processor maybe configured to receive during a first time period, via thecommunications interface, a first request for a shared-ride from a firstuser (e.g., user P1). The first request including information indicativeof a first starting point, a first desired destination, and a firstrequested pick-up time, wherein the first requested pick-up time isduring a second time period more than a first time interval after thefirst time period, where the first time interval can be e.g. 10 minutes,30 minutes, two hours, 24 hours, etc. The at least one processor mayalso be configured to receive during a third time period, via thecommunications interface, a second request for a shared ride from asecond user (e.g., user OD1), where the third time period is after thefirst time period but before the second time period. The second requestmay include information indicative of a second starting point differentfrom the first starting point, and a second desired destinationdifferent from the first desired destination. During the third timeperiod, the at least one processor may be configured to receive currentvehicle location data for a plurality of ridesharing vehicles, whereinthe current vehicle location data includes global positioning system(GPS) data generated by at least one GPS component associated with eachof the plurality of ridesharing vehicles; process the first request, thesecond request, and the vehicle location data to identify a specificridesharing vehicle for transporting both the first user and the seconduser; and calculate a ridesharing route for picking up the first userand the second user, wherein calculating the ridesharing route includesdetermining pick-up locations for the first user and the second userthat differ from the first starting point and the second starting point.After the third time period and before the second time period, the atleast one processor may be configured to wirelessly transmit to thefirst user and the second user the respective pick-up locations; andwireless transmit to the specific ridesharing vehicle, the calculatedroute for picking up the first and second user.

Reference is now made to FIG. 23, which depicts an exemplary method 2300for directing ridesharing vehicles consistent with the presentdisclosure. In one embodiment, the steps of method 2300 may be performedby ridesharing management system 100 or automated ridesharing dispatchsystem 300. In the following description, reference is made to certaincomponents of ridesharing management server 150 for purposes ofillustration. It will be appreciated, however, that otherimplementations are possible and that other components may be utilizedto implement the exemplary method. It will be readily appreciated thatthe illustrated method can be altered to modify the order of steps,delete steps, or further include additional steps.

At step 2302, during a first time period, a communications interface(e.g., communications interface 360) may receive a first request for ashared-ride from a first user, the first request including informationindicative of a first starting point, a first desired destination, and afirst requested pick-up time. The first requested pick-up time may beduring a second time period more than two hours after the first timeperiod. At step 2304, during the first time period, the communicationsinterface may receive a second request for a shared ride from a seconduser, the second request including information indicative of a secondstarting point different from the first starting point, a second desireddestination different from the first desired destination, and a secondrequested pick-up time during the second time period. As describedabove, the starting point may refer to a current location of the firstand second users, as inputted by the first and second users through anassociated user device, or as determined by a location serviceapplication installed on the associated user device. In someembodiments, a starting point may be a location different from thecurrent location of a user, for example, a location the user isscheduled to be in about the requested pick-up time. A desireddestination may refer to a location a user requests to be taken to. Arequested pick-up time may be associated with or calculated from thetime a user wants to reach the desired destination. Also, each riderequest may include additional information, for example, informationidentifying the user, a selection of a type of ridesharing service, anindication of a maximum walking distance, and more.

At step 2306, during the first time period, a processing device (e.g.,processor 310) may store the first and second requests for processingduring a third time period. The third time period for processing is morethan one hour after the first time period but before the second timeperiod. The first and second requests may be stored in a memory device(e.g., memory 320 or database 2114). In one embodiment, the processingdevice is configured to determine a time for processing the first andsecond requests and to record a future event in the system (e.g., inrequests management module 2104) at the determined time. For example,the processing device may store more than a hundred requests for futureprocessing, and each of the more than a hundred requests may beassociated with a different time for processing.

At step 2308, during the third time period, the communications interfacemay receive current vehicle location data for a plurality of ridesharingvehicles, wherein the current vehicle location data includes globalpositioning system (GPS) data generated by at least one GPS componentassociated with each of the plurality of ridesharing vehicles. In oneexample, the plurality of communication devices may include mobiledevices such as tablets or smartphones that belong to the drivers of theridesharing vehicles. In another example, the plurality of ridesharingvehicles may include multiple smart vehicles and each communicationdevice may be a component of a smart vehicle. The term “smart vehicles”refers to vehicles (e.g., autonomously and/or manually-driven) withcomputing resources, location determination components, andcommunication devices. A smart vehicle may communicate with ridesharingmanagement system 100 independently to the driver or to a driver'scommunication device.

At step 2310, during the third time period, the processing device mayprocess the first request, the second request, and the vehicle locationdata to identify a specific ridesharing vehicle for transporting boththe first user and the second user. Consistent with the presentdisclosure, the processing device may be further configured to selectthe specific ridesharing vehicle for transporting both the first userand the second user based on at least some of the following parameters:the location of the ridesharing vehicle, the driving direction of theridesharing vehicle, the driving route of the ridesharing vehicle, thenumber of passengers riding the ridesharing vehicle, the number of usersassigned to the ridesharing vehicle and scheduled to be picked up, thevirtual bus stops that the ridesharing vehicle is scheduled to stop at,the desired destinations of all the users assigned to the ridesharingvehicle, the real time traffic data, the user's starting point, theuser's desired destination, the user's personal preferences, and thetype of service the user selected.

At step 2312, during the third time period, the processing device maycalculate a ridesharing route for picking up the first user and thesecond user. The calculated route may include a plurality of pick-up anddrop-off locations associated with the starting points and desireddestinations of the plurality of users. Consistent with the presentdisclosure, calculating the ridesharing route may include determiningpick-up locations for the first user and the second user that differfrom the first starting point and the second starting point. Consistentwith some embodiments, the processing device may calculate the route forpicking up the first user and the second user based on shared-riderequests of on-demand users. In one example, the pick-up locations ofthe first user and the second user may be determined based on a startingpoint (or a desired destination) of an on-demand user requesting a rideat the third-period of time (or after the third-period of time). Inanother example, the drop-off locations of the first user and the seconduser may be determined based on a starting point (or a desireddestination) of an on-demand user requesting a ride while the first userand the second user are riding the specific ridesharing vehicle.

At step 2314, after the third time period and before the second timeperiod, the processing device may wirelessly transmit to the first userand the second user the respective pick-up locations, and at step 2316the processing device may wirelessly transmit to the specificridesharing vehicle the calculated route for picking up the first andsecond user during the second time period. Consistent with the presentdisclosure, the processing device may wirelessly transmit to the firstuser and the second user the respective pick-up locations at a timecloser to the second time period than the first time period.

The foregoing description has been presented for purposes ofillustration. It is not exhaustive and is not limited to the preciseforms or embodiments disclosed. Modifications and adaptations will beapparent to those skilled in the art from consideration of thespecification and practice of the disclosed embodiments. Additionally,although aspects of the disclosed embodiments are described as beingstored in memory, one skilled in the art will appreciate that theseaspects can also be stored on other types of computer readable media,such as secondary storage devices, e.g., hard disks or CD ROM, or otherforms of RAM or ROM, USB media, DVD, Blu-ray, Ultra HD Blu-ray, or otheroptical drive media.

Computer programs based on the written description and disclosed methodsare within the skills of an experienced developer. The various programsor program modules can be created using any of the techniques known toone skilled in the art or can be designed in connection with existingsoftware. For example, program sections or program modules can bedesigned in or by means of .Net Framework, .Net Compact Framework (andrelated languages, such as Visual Basic, C, etc.), Java, C++,Objective-C, HTML, HTML/AJAX combinations, XML, or HTML with includedJava applets.

Moreover, while illustrative embodiments have been described herein, thescope of any and all embodiments having equivalent elements,modifications, omissions, combinations (e.g., of aspects across variousembodiments), adaptations and/or alterations as would be appreciated bythose skilled in the art based on the present disclosure. The examplesare to be construed as non-exclusive. Furthermore, the steps of thedisclosed methods may be modified in any manner, including by reorderingsteps and/or inserting or deleting steps. It is intended, therefore,that the specification and examples be considered as illustrative only.

1. A ridesharing vehicle, comprising: a vehicle body; a communicationsinterface within the vehicle body for wirelessly communicating with aremote server configured to electronically receive shared-ride requestsfrom a plurality of users; at least one sensor associated with thevehicle body and configured to detect entry of passengers from theridesharing vehicle; at least one processor within the vehicle body, theat least one processor being programmed to: receive, via thecommunications interface, information about passengers to be picked up,the received information including a pick-up location and a schedulednumber of passengers expected to be picked up at the pick-up location;after arriving at the pick-up location, receive from the at least onesensor a number of passengers actually picked up at the pick-uplocation; compare the actual number of passengers picked up at thepick-up location with the scheduled number of passengers; and initiate aremedial action when a difference exists between the scheduled number ofpassengers and the actual number of passengers as detected by the atleast one sensor.
 2. The ridesharing vehicle of claim 1, wherein theremedial action includes providing at least one of audio or visualfeedback within the ridesharing vehicle.
 3. The ridesharing vehicle ofclaim 1, wherein the remedial action includes wirelessly transmitting anindication of the difference to the remote server.
 4. The ridesharingvehicle of claim 3, wherein transmitting the indication enables theremote server to reassign a pending pickup to a ridesharing vehicle. 5.The ridesharing vehicle of claim 3, wherein transmitting the indicationenables the remote server to take into account the current number ofpassengers in the vehicle when making future assignments of passengersto the ridesharing vehicle.
 6. The ridesharing vehicle of claim 1,wherein the remedial action includes identifying an unscheduledpassenger and determining a desired destination of the unscheduledpassenger.
 7. The ridesharing vehicle of claim 1, wherein the at leastone sensor includes at least one of: an infrared sensor, a volumetricsensor, a weight sensor, a proximity sensor, and an image sensor.
 8. Theridesharing vehicle of claim 1, wherein the at least one processor isfurther programmed to facilitate determination of identities ofpassengers.
 9. The ridesharing vehicle of claim 8, wherein the at leastone sensor includes an image sensor, and wherein facilitatingdetermination includes comparing image data from the image sensor withimage-related data wirelessly received.
 10. The ridesharing vehicle ofclaim 8, wherein the at least one sensor includes an image sensor, andwherein facilitating determination includes causing data from the imagesensor to be wirelessly transmitted to a remote server for passengeridentity confirmation at the remote server.
 11. The ridesharing vehicleof claim 1, wherein the at least one processor is further programmed toreceive, via the communications interface, identifying information froma mobile communications device of a passenger and to thereby confirm anidentity of the passenger based on data obtained from the mobilecommunications device.
 12. The ridesharing vehicle of claim 1, whereinthe information about passengers to be picked up includes an indicationof scheduled passenger's luggage capable of impacting capacity of theridesharing vehicle.
 13. The ridesharing vehicle of claim 1, wherein theinformation about passengers to be picked up includes details of atleast two shared-ride requests associated with the scheduled number ofpassengers expected to be picked up at the pick-up location; and the atleast one processor is further configured to identify which of the atleast two shared-ride requests associated with the difference existsbetween the scheduled number of passengers and the actual number ofpassengers.
 14. The ridesharing vehicle of claim 11, wherein the atleast one processor is further programmed to: after arriving at thepick-up location, receive from the at least one sensor an indication ofpassenger's luggage actually picked up at the pick-up location; comparethe actual passenger's luggage picked up at the pick-up location withthe scheduled passenger's luggage associated with the pick-up location;and initiate a remedial action when a difference exists between thescheduled passenger's luggage received via the wireless connection andthe actual passenger's luggage as detected by the at least one sensor.15. The ridesharing vehicle of claim 1, wherein the at least oneprocessor is further configured to receive, via the communicationsinterface, information about a drop-off location and a number ofpassengers scheduled to departure at the drop-off location.
 16. Theridesharing vehicle of claim 15, wherein the at least one sensor isfurther configured to detect one or more passengers exiting from theridesharing vehicle and the at least one processor is further programmedto: after arriving at the drop-off location, receive from the at leastone sensor a number of passengers actually departed at the drop-offlocation; compare the actual number of passengers departed at thedrop-off location with the scheduled number of passengers associatedwith the drop-off location; and initiate a remedial action when adifference exists between the number of passengers scheduled todeparture at the drop-off location and the actual number of passengersdeparted at the drop-off location.
 17. The ridesharing vehicle of claim1, wherein the remedial action includes a first action if the schedulednumber of passengers is less than the actual number of passengers asdetected by the at least one sensor, and the remedial action includes asecond action if the scheduled number of passengers is greater than theactual number of passengers as detected by the at least one sensor, thefirst action being different from the second action.
 18. A method forcounting a number of passengers entering a ridesharing vehicle, themethod comprising: receiving from a remote server information aboutpassengers to be picked up, the received information including a pick-uplocation and a scheduled number of passengers expected to be picked upat the pick-up location; receiving, from at least one sensor configuredto detect entry of passengers from the ridesharing vehicle, a number ofpassengers actually picked up at the pick-up location; comparing theactual number of passengers picked up at the pick-up location with thescheduled number of passengers; and initiating a remedial action when adifference exists between the scheduled number of passengers and theactual number of passengers as detected by the at least one sensor. 19.The method of claim 18, wherein the remedial action includes wirelesslytransmitting the difference to the remote server.
 20. The method ofclaim 19, wherein communicating the difference is provided to enable theremote server to take into account the current number of passengers inthe vehicle when making future assignments of passengers to theridesharing vehicle.
 21. The method of claim 18, wherein the remedialaction includes identifying an unscheduled passenger and determining adesired destination of the unscheduled passenger.
 22. A non-transitorycomputer-readable storage medium storing instructions that, whenexecuted by at least one processor, cause the at least one processor toperform a method for counting a number of passengers entering aridesharing vehicle, the method comprising: receiving from a remoteserver information about passengers to be picked up, including a pick-uplocation and a scheduled number of passengers expected to be picked upat the pick-up location; receiving, from at least one sensor configuredto detect entry of passengers from the ridesharing vehicle, a number ofpassengers actually picked up at the pick-up location; comparing theactual number of passengers picked up at the pick-up location with thescheduled number of passengers; and initiating a remedial action when adifference exists between the scheduled number of passengers and theactual number of passengers. 23-127. (canceled)